3 ms·

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

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.

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.