6 ms·

A bit of a nitpick, but the stock trading question should have stated up front that short-selling was not allowed or that the purchase order must precede the se

A bit of a nitpick, but the stock trading question should have stated up front that short-selling was not allowed or that the purchase order must precede the sell order. (I suspect someone with some familiarity with trading would have asked these questions in an actual interview for clarification) Relying on a "hint" to figure out that you can only sell after you buy seems more like an additional constraint rather than a true hint.

deleted 13y ago
[deleted]
mehrdada 13y ago
Indeed. Having had quite a bit of experience with ACM-type competitions, I believe it is super-important for technical coding questions not to leave room for misinterpretation (especially when the key point being tested relies on the accurate interpretation, like this case.) Being sloppy in the interview may lead a bad taste in the mouth of the best candidates, because they are the ones who will take the question most literally. It's not an excuse to leave things like that vague so that a candidate would have to bring it up to you. If you want to ask open-ended questions, ask obviously open-ended questions; don't make an attempt to turn simple technical questions into open-ended ones.
- stygiansonic 13y ago
  Agreed. I feel that if a question is going to be about a "real world" situation like trading stocks, it should reflect real world constraints that should be stated up front. I also found it curious that the example listed the stock price at 1 AM. It would be far more of a real world example to only consider times during the normal trading hours. A question phrased about a particular real-world domain that doesn't makes sense within that domain just doesn't seem fair to ask. But again, total nitpick on my part. The actual format in which the questions were presented was generally done well, and a nice refresh from the typical "interview prep" sites.
gt384u 13y ago
I feel like completely specifying the problem does everyone in an actual engineering interview a disservice and isn't a good analogue to actual engineering problem-solving. That said, it might be acceptable or even encouraged for the purposes of this site. In the case that you mention, if someone asked me "Can I short sell?" I'd be happy that they considered the order of events there and were trying to explore the problem. I'd certainly remember it in my interview feedback. My response as an interviewer would be more or less "That's an interesting thought. To simplify the problem, let's say we're risk averse and prefer a finite loss potential. Go ahead and just consider purchase before sale." One of the biggest criteria I looked for from junior engineering candidates was that they didn't just jump into implementation and asked clarifying questions. That's hard to do with the sort of site this is so maybe in this case more complete specification is useful, but any way that a bit of ambiguity can be introduced means that you can have a meaningful conversation with an engineer about representation, the shape of the problem, the inputs, what the criteria for success are, what is truly necessary to solve a problem. I want working code in the end, but hearing the things a person does or does not consider about a problem is interesting and valuable to understand a potential teammate and how they think.
- stygiansonic 13y ago
  I don't have a problem with a vague question and in fact a candidate asking clarifying questions is indeed a Good Thing. However the way the question was phrased just makes it seem like the person who phrased it doesn't understand how trading works in real markets.
cpwright 13y ago
My first thought was that just getting a min and a max was the right answer, mainly because I having something hard-to-borrow is the edge case; and that the general case is that you can short.
jimmaswell 13y ago
why would I need a hint that I can't time-travel? why would I need to be familiar with trading to know I can't sell something I bought in the future?
- stygiansonic 13y ago
  Short-selling does not involve time-travel.
  - jimmaswell 13y ago
    It said in the text of the problem that you have to purchase the stock, not pretend to purchase the stock.
coupdejarnac 13y ago
Indeed. Or this becomes an exercise in calling sort().

deleted 13y ago

[deleted]

mehrdada 13y ago

Indeed. Having had quite a bit of experience with ACM-type competitions, I believe it is super-important for technical coding questions not to leave room for misinterpretation (especially when the key point being tested relies on the accurate interpretation, like this case.) Being sloppy in the interview may lead a bad taste in the mouth of the best candidates, because they are the ones who will take the question most literally. It's not an excuse to leave things like that vague so that a candidate would have to bring it up to you. If you want to ask open-ended questions, ask obviously open-ended questions; don't make an attempt to turn simple technical questions into open-ended ones.

stygiansonic 13y ago
Agreed. I feel that if a question is going to be about a "real world" situation like trading stocks, it should reflect real world constraints that should be stated up front. I also found it curious that the example listed the stock price at 1 AM. It would be far more of a real world example to only consider times during the normal trading hours. A question phrased about a particular real-world domain that doesn't makes sense within that domain just doesn't seem fair to ask. But again, total nitpick on my part. The actual format in which the questions were presented was generally done well, and a nice refresh from the typical "interview prep" sites.

gt384u 13y ago

I feel like completely specifying the problem does everyone in an actual engineering interview a disservice and isn't a good analogue to actual engineering problem-solving. That said, it might be acceptable or even encouraged for the purposes of this site. In the case that you mention, if someone asked me "Can I short sell?" I'd be happy that they considered the order of events there and were trying to explore the problem. I'd certainly remember it in my interview feedback. My response as an interviewer would be more or less "That's an interesting thought. To simplify the problem, let's say we're risk averse and prefer a finite loss potential. Go ahead and just consider purchase before sale." One of the biggest criteria I looked for from junior engineering candidates was that they didn't just jump into implementation and asked clarifying questions. That's hard to do with the sort of site this is so maybe in this case more complete specification is useful, but any way that a bit of ambiguity can be introduced means that you can have a meaningful conversation with an engineer about representation, the shape of the problem, the inputs, what the criteria for success are, what is truly necessary to solve a problem. I want working code in the end, but hearing the things a person does or does not consider about a problem is interesting and valuable to understand a potential teammate and how they think.

stygiansonic 13y ago
I don't have a problem with a vague question and in fact a candidate asking clarifying questions is indeed a Good Thing. However the way the question was phrased just makes it seem like the person who phrased it doesn't understand how trading works in real markets.

cpwright 13y ago

My first thought was that just getting a min and a max was the right answer, mainly because I having something hard-to-borrow is the edge case; and that the general case is that you can short.

jimmaswell 13y ago

why would I need a hint that I can't time-travel? why would I need to be familiar with trading to know I can't sell something I bought in the future?

stygiansonic 13y ago
Short-selling does not involve time-travel.
- jimmaswell 13y ago
  It said in the text of the problem that you have to purchase the stock, not pretend to purchase the stock.

coupdejarnac 13y ago

Indeed. Or this becomes an exercise in calling sort().