3 ms·

I disagree this is actually a good question. Also I would have been a type 1 person, mostly becasue I would have assumed there's some clever trick to it, since

by tayo42 3y ago

I disagree this is actually a good question. Also I would have been a type 1 person, mostly becasue I would have assumed there's some clever trick to it, since we're in an interview.

albert_e 3y ago
I was thinking on the lines of Type 1 myself -- some reasons I can think of in hindsight: 1. I assumed that low-level code and performance optimization was not the ask (given it was a mere three hour programming challenge with a unfamiliar codebase) 2. The very elaborate description of Incr, Decr with emphasis on atomicity and multiple clients -- was heavily leading us towards thinking about how to utilize the already implemented, stable, and presumably finely performance-optimized functionality -- rather than re-implement your own. So I assumed it was a test of design thinking where you can apply the concept of atomicity, parallelizable operations, resolving conflicts / locks / race conditions etc. If they are looking for talent in Type 2 space where they can do incremental edits to a codebase powered mostly by copy-paste -- I am not sure this intervew question is for roles that need the highest levels of generic problem solving needed from experienced Software Developers who will drive software design. Also if implementing Mult was so straightforward that it can be done so thoroughly (including tests) in under three -hours by a single person that is opening the code base for the first time; Then why had this feature not been implemented already by then by the original project maintainers? I am sure I can find some use cases where there is a need to do multiplication of an in-memory numeric value say in gaming, cypto, etc. in order to justify this feature addition.
- xw31099 3y ago
  > Also if implementing Mult was so straightforward that it can be done so thoroughly (including tests) in under three -hours by a single person that is opening the code base for the first time; Then why had this feature not been implemented already by then by the original project maintainers? Exactly. That set off my warning bells too.
  - FabHK 3y ago
    Right. So if interviewers come up with an artificial contrived ("leet") problem, then candidates complain that it's an artificial contrived problem. When they come up with a realistic straightforward problem, then candidates complain that it should have been solved already.
- xarope 3y ago
  I'd also assume that Mult can lead to overflow very easily, and if I'm not wrong, the solution proposed also doesn't check for such overflow/wrap around. So I'd also concur that someone who blindly copy-pasted a "+" and changed everything to "*", doesn't really understand the difference between + and *.
  - csande17 3y ago
    Is there a difference, in this case? Addition can also overflow.
    - xarope 3y ago
      not as dramatically as mult can. and besides, if addition overflows, then it behooves you to ensure your next implementation doesn't, otherwise you are just adding technical debt.
    - xxs 3y ago
      Yes, I mentioned in a sibling answer - the mul overflows much easier and detecting is much harder, hence it uses two registers in the CPU for the result. Detecting sub/add overflow is a single CPU flag.
  - xxs 3y ago
    That was my 1st thought. Traditionally the mul CPU instruction uses two registers for the result, as the expectation is that it overflows. Add/sub needs only a single overflow/signed flag. OTOH, it's 64bit and only unsigned, so yeah 64 bit gotta be enough for everyone (unlike 640KB mem)?
- csande17 3y ago
  I think it's useful to have an interview question to identify engineers who, when faced with "add 'multiply' to a codebase that already supports 'add' and 'subtract'", conclude that it's an unimaginably complex design problem requiring the highest levels of generic problem solving. Lots of teams are looking for people like that, but not all of them are.
  - albert_e 3y ago
    Agreed. Usually there is a lot of course correction that happens when there are at least two people / two brains working on a problem and bouncing off ideas. Unfortunately that is completely missing in such interview scenarios. Hiring Type 1 is not a mistake unless that person is also rigid / headstrong and always goes for an overengineered solution.
mrweasel 3y ago
While I still think it's a good way to assess how a person works, by actually making them work, I do agree that there's an issue with people thinking that there's some trick. We've just completed a series of interviews and everyone below a certain age seems to think that we're pulling all kinds of tricks. During our interviews we'll ask a series of fairly simple questions about programming, operations, deployment, monitoring, all sorts of things. It's pretty clear to me that some candidates completely overthinks the problem. This was for a number of entry level jobs, so expectations aren't all that high, but we do want to make sure that people know the basics. It completely throws of a large number of people, especially those who have worked in startups and larger companies in the Silicon Valley / San Francisco areas. Our older candidate frequently just straight up answer the question and just comment "Or where you looking for something in particular?" Normally we're not. This is more a result of absolutely broken interview processes at other companies. I don't see us changing our interview process to include trick questions. Our questions are intended to make people talk, that's it.
ZephyrBlu 3y ago
Why would you automatically assume there's a clever trick instead of breaking the problem down and making assumptions like an engineer? Very odd to me that you wouldn't see the question and think "multiplication is a pretty similar operation to addition, let's find the increment implementation and go from there".
- tayo42 3y ago
  Idk becasue I have some kind of trauma from interviewing I guess. And there is no clear description of what is being tested for with this test. I would have done multiplication in terms of addition since the code exists or look up how multiplication has been implemented by other projects. Imo what he ends up calling type 1 is probably more along the lines of good engineering instead of copy and paste,which I would consider poor engineering. Again it's not clear what is being tested for though.
  - ZephyrBlu 3y ago
    It's pretty clear to me what's being tested: do you have strong fundamental engineering skills. This kind of problem/situation is a very common pattern. Honestly it sounds like you don't have good engineering intuition. Type 1 engineers as he described them aren't great engineers because they tend to get stuck in analysis paralysis. They don't have good enough intuition to make the right assumptions about the problem that allow them to continue moving forwards. Do you really need to dig into the e.g. locking mechanism? Probably not, because it should be abstracted away or be used/implemented in the incr codepath, which you can copy. Why are you so scared about implementing new multiplication functionality? Do you not trust your ability to figure out a robust solution based on addition? In my experience, Type 1 engineers do not tend to break problems down correctly. You need to break things down so that you can validate/invalidate your assumptions. Having vague concerns that a multiplication implementation might break tends to belie a lack of understanding and trust, since otherwise you would either have specific concerns or be able to use your intuition to make assumptions about the system. "good engineering" is not about going through every detail of a system, it's being able to reason about problems, approaches and solutions coherently and pragmatically.

by tayo42 3y ago

I disagree this is actually a good question. Also I would have been a type 1 person, mostly becasue I would have assumed there's some clever trick to it, since we're in an interview.

albert_e 3y ago

I was thinking on the lines of Type 1 myself -- some reasons I can think of in hindsight: 1. I assumed that low-level code and performance optimization was not the ask (given it was a mere three hour programming challenge with a unfamiliar codebase) 2. The very elaborate description of Incr, Decr with emphasis on atomicity and multiple clients -- was heavily leading us towards thinking about how to utilize the already implemented, stable, and presumably finely performance-optimized functionality -- rather than re-implement your own. So I assumed it was a test of design thinking where you can apply the concept of atomicity, parallelizable operations, resolving conflicts / locks / race conditions etc. If they are looking for talent in Type 2 space where they can do incremental edits to a codebase powered mostly by copy-paste -- I am not sure this intervew question is for roles that need the highest levels of generic problem solving needed from experienced Software Developers who will drive software design. Also if implementing Mult was so straightforward that it can be done so thoroughly (including tests) in under three -hours by a single person that is opening the code base for the first time; Then why had this feature not been implemented already by then by the original project maintainers? I am sure I can find some use cases where there is a need to do multiplication of an in-memory numeric value say in gaming, cypto, etc. in order to justify this feature addition.

xw31099 3y ago
> Also if implementing Mult was so straightforward that it can be done so thoroughly (including tests) in under three -hours by a single person that is opening the code base for the first time; Then why had this feature not been implemented already by then by the original project maintainers? Exactly. That set off my warning bells too.
- FabHK 3y ago
  Right. So if interviewers come up with an artificial contrived ("leet") problem, then candidates complain that it's an artificial contrived problem. When they come up with a realistic straightforward problem, then candidates complain that it should have been solved already.
xarope 3y ago
I'd also assume that Mult can lead to overflow very easily, and if I'm not wrong, the solution proposed also doesn't check for such overflow/wrap around. So I'd also concur that someone who blindly copy-pasted a "+" and changed everything to "*", doesn't really understand the difference between + and *.
- csande17 3y ago
  Is there a difference, in this case? Addition can also overflow.
  - xarope 3y ago
    not as dramatically as mult can. and besides, if addition overflows, then it behooves you to ensure your next implementation doesn't, otherwise you are just adding technical debt.
  - xxs 3y ago
    Yes, I mentioned in a sibling answer - the mul overflows much easier and detecting is much harder, hence it uses two registers in the CPU for the result. Detecting sub/add overflow is a single CPU flag.
- xxs 3y ago
  That was my 1st thought. Traditionally the mul CPU instruction uses two registers for the result, as the expectation is that it overflows. Add/sub needs only a single overflow/signed flag. OTOH, it's 64bit and only unsigned, so yeah 64 bit gotta be enough for everyone (unlike 640KB mem)?
csande17 3y ago
I think it's useful to have an interview question to identify engineers who, when faced with "add 'multiply' to a codebase that already supports 'add' and 'subtract'", conclude that it's an unimaginably complex design problem requiring the highest levels of generic problem solving. Lots of teams are looking for people like that, but not all of them are.
- albert_e 3y ago
  Agreed. Usually there is a lot of course correction that happens when there are at least two people / two brains working on a problem and bouncing off ideas. Unfortunately that is completely missing in such interview scenarios. Hiring Type 1 is not a mistake unless that person is also rigid / headstrong and always goes for an overengineered solution.

mrweasel 3y ago

While I still think it's a good way to assess how a person works, by actually making them work, I do agree that there's an issue with people thinking that there's some trick. We've just completed a series of interviews and everyone below a certain age seems to think that we're pulling all kinds of tricks. During our interviews we'll ask a series of fairly simple questions about programming, operations, deployment, monitoring, all sorts of things. It's pretty clear to me that some candidates completely overthinks the problem. This was for a number of entry level jobs, so expectations aren't all that high, but we do want to make sure that people know the basics. It completely throws of a large number of people, especially those who have worked in startups and larger companies in the Silicon Valley / San Francisco areas. Our older candidate frequently just straight up answer the question and just comment "Or where you looking for something in particular?" Normally we're not. This is more a result of absolutely broken interview processes at other companies. I don't see us changing our interview process to include trick questions. Our questions are intended to make people talk, that's it.

ZephyrBlu 3y ago

Why would you automatically assume there's a clever trick instead of breaking the problem down and making assumptions like an engineer? Very odd to me that you wouldn't see the question and think "multiplication is a pretty similar operation to addition, let's find the increment implementation and go from there".

tayo42 3y ago
Idk becasue I have some kind of trauma from interviewing I guess. And there is no clear description of what is being tested for with this test. I would have done multiplication in terms of addition since the code exists or look up how multiplication has been implemented by other projects. Imo what he ends up calling type 1 is probably more along the lines of good engineering instead of copy and paste,which I would consider poor engineering. Again it's not clear what is being tested for though.
- ZephyrBlu 3y ago
  It's pretty clear to me what's being tested: do you have strong fundamental engineering skills. This kind of problem/situation is a very common pattern. Honestly it sounds like you don't have good engineering intuition. Type 1 engineers as he described them aren't great engineers because they tend to get stuck in analysis paralysis. They don't have good enough intuition to make the right assumptions about the problem that allow them to continue moving forwards. Do you really need to dig into the e.g. locking mechanism? Probably not, because it should be abstracted away or be used/implemented in the incr codepath, which you can copy. Why are you so scared about implementing new multiplication functionality? Do you not trust your ability to figure out a robust solution based on addition? In my experience, Type 1 engineers do not tend to break problems down correctly. You need to break things down so that you can validate/invalidate your assumptions. Having vague concerns that a multiplication implementation might break tends to belie a lack of understanding and trust, since otherwise you would either have specific concerns or be able to use your intuition to make assumptions about the system. "good engineering" is not about going through every detail of a system, it's being able to reason about problems, approaches and solutions coherently and pragmatically.