5 ms·

Why is the type1 programmer being looked down upon? I mean I am sure that I want to make sure how the lock implementation is. I also want to know if it is modul

Why is the type1 programmer being looked down upon? I mean I am sure that I want to make sure how the lock implementation is. I also want to know if it is modular enough to be called somewhere or is it baked in the add step. I sure do want to multiple times read the add implementation and make sure there isn't a magic somewhere. And finally this problem looks a lot like can you see a pattern!! I mean sure but a lot of people who might go to interview with standards of competitive programming might take the whole 3 hours because there's a lot to rule out. I guess this is a fair question with a proper IDE and grep tools. The timing does look outrageous but if you are interviewing at a company which builds databases as a product, you better know how basic operations are provided. Redis source code is fun to read as well.

ankrgyl 5y ago
Fun fact: we tried it out with Redis, but the question worked out to be too easy because of how nicely the codebase is laid out.
- CamperBob2 5y ago
  Now that's a compliment. "We couldn't use your code as a basis for interviews because it was too obvious how it worked and how to modify it." Definitely a condition worth striving for.
- deleted 5y ago
  [deleted]
ww520 5y ago
Yes, type1 is actually better than type2. Type2 is hyper-focus and is just blindly copying and pasting the incr portion as multi. Type1 actually is curious about the code base and wants to explore it a bit, to see how the locking is working and validate its correctness, to explore different approaches to see if incr can be used to implement multi. Type1 will end up learning a lot more about the codebase and do well in the long term.
- californical 5y ago
  Definitely yes! Type 2 will get a result out faster, but they’re less likely to pick up on complicated patterns that have emerged within the system, and may not reach a point where they understand all of the parts and how they combine. Type 1 will definitely take longer at first, but given a few months in your codebase, they’ll be able to make more effective trade-offs and understand the system better as a whole. Talking generally of course, there are probably some type-2’s that will still find time to prod around, and some type-1’s that will never get faster… but I think someone who doesn’t just assume that their guess about how a system works is correct, will be more likely to produce quality code in the long term.
ip26 5y ago
That was my reaction as well. To me, it seems like you cannot take it for granted that the existing locking, adequate for incr, is also adequate for mult. It could be that in database circles, nobody ever uses any magic and only very strong locks are employed, and perhaps the candidate is supposed to be aware of this.
- ww520 5y ago
  Yes, I can think of couple ways to do lockless atomic increment/decrement but those won't translate well to multiply. Blindly assuming incr/decr using a generic lock that can cover multi as well without understanding how atomic operation work in the product is asking for trouble down the road.
- ankrgyl 5y ago
  You can't take that for granted, but it turns out in practice that memcached does not use atomic add, and so it happens to be straightforward to support multiplication with the same set of locks.
  - EdwardDiego 5y ago
    Where is that documented? I couldn't find any docs on concurrent writes.
- grog454 5y ago
  I think the question (as presented) simply doesn't select for this kind of analysis and as long as the asker is aware of that, it's not a problem.
deleted 5y ago
[deleted]
zamfi 5y ago
I think it depends on the need of the company. I’m reminded of Joel Spolsky’s “smart and gets shit done” adage (and then book): type 1 is smart, and you want some of these people. But you don’t want people who, then faced with a task that can take 3 hours-and has been given time pressure that requires it to take 3 hours—instead spend 12 hours because they can’t live with the ambiguity of being uncertain that they’re using locks the right way. The approach described in part 2 is highly opportunistic. You generally want to hire staff who can be opportunistic when necessary, even if that is not always the right approach.
- ip26 5y ago
  Ironically I would argue concurrency is the ONE place where a gnawing intolerance of ambiguity might actually be a good thing ;) (As broken concurrency is one of the worst forms of Heisenbug)
  - underdeserver 5y ago
    Exactly. Type 2s are great at getting things done, but the team's going to have to wake up at 3 AM on a weekend because of random errors.
    - zamfi 5y ago
      Perhaps. But for some companies, the occasional 3am page is worth the tradeoff for development to happen (at least in this reading) 4x faster.
      - underdeserver 5y ago
        It's also not 4x faster. It's only 4x faster at the very beginning, until all the weird bugs get in the way and everyone's too scared to make changes because every little change breaks the customer experience.
        underdeserver 5y ago
EdwardDiego 5y ago
I agree. I haven't been near this code base at all, but after a quick glance at the docs that do exist, I can't see anything about concurrency design. If thinking about safe concurrent writes is wrong, then I don't want to be writing code for you...

ankrgyl 5y ago

Fun fact: we tried it out with Redis, but the question worked out to be too easy because of how nicely the codebase is laid out.

CamperBob2 5y ago
Now that's a compliment. "We couldn't use your code as a basis for interviews because it was too obvious how it worked and how to modify it." Definitely a condition worth striving for.
deleted 5y ago
[deleted]

ww520 5y ago

Yes, type1 is actually better than type2. Type2 is hyper-focus and is just blindly copying and pasting the incr portion as multi. Type1 actually is curious about the code base and wants to explore it a bit, to see how the locking is working and validate its correctness, to explore different approaches to see if incr can be used to implement multi. Type1 will end up learning a lot more about the codebase and do well in the long term.

californical 5y ago
Definitely yes! Type 2 will get a result out faster, but they’re less likely to pick up on complicated patterns that have emerged within the system, and may not reach a point where they understand all of the parts and how they combine. Type 1 will definitely take longer at first, but given a few months in your codebase, they’ll be able to make more effective trade-offs and understand the system better as a whole. Talking generally of course, there are probably some type-2’s that will still find time to prod around, and some type-1’s that will never get faster… but I think someone who doesn’t just assume that their guess about how a system works is correct, will be more likely to produce quality code in the long term.

ip26 5y ago

That was my reaction as well. To me, it seems like you cannot take it for granted that the existing locking, adequate for incr, is also adequate for mult. It could be that in database circles, nobody ever uses any magic and only very strong locks are employed, and perhaps the candidate is supposed to be aware of this.

ww520 5y ago
Yes, I can think of couple ways to do lockless atomic increment/decrement but those won't translate well to multiply. Blindly assuming incr/decr using a generic lock that can cover multi as well without understanding how atomic operation work in the product is asking for trouble down the road.
ankrgyl 5y ago
You can't take that for granted, but it turns out in practice that memcached does not use atomic add, and so it happens to be straightforward to support multiplication with the same set of locks.
- EdwardDiego 5y ago
  Where is that documented? I couldn't find any docs on concurrent writes.
grog454 5y ago
I think the question (as presented) simply doesn't select for this kind of analysis and as long as the asker is aware of that, it's not a problem.

deleted 5y ago

[deleted]

zamfi 5y ago

I think it depends on the need of the company. I’m reminded of Joel Spolsky’s “smart and gets shit done” adage (and then book): type 1 is smart, and you want some of these people. But you don’t want people who, then faced with a task that can take 3 hours-and has been given time pressure that requires it to take 3 hours—instead spend 12 hours because they can’t live with the ambiguity of being uncertain that they’re using locks the right way. The approach described in part 2 is highly opportunistic. You generally want to hire staff who can be opportunistic when necessary, even if that is not always the right approach.

ip26 5y ago
Ironically I would argue concurrency is the ONE place where a gnawing intolerance of ambiguity might actually be a good thing ;) (As broken concurrency is one of the worst forms of Heisenbug)
- underdeserver 5y ago
  Exactly. Type 2s are great at getting things done, but the team's going to have to wake up at 3 AM on a weekend because of random errors.
  - zamfi 5y ago
    Perhaps. But for some companies, the occasional 3am page is worth the tradeoff for development to happen (at least in this reading) 4x faster.
    - underdeserver 5y ago
      It's also not 4x faster. It's only 4x faster at the very beginning, until all the weird bugs get in the way and everyone's too scared to make changes because every little change breaks the customer experience.
      - underdeserver 5y ago

EdwardDiego 5y ago

I agree. I haven't been near this code base at all, but after a quick glance at the docs that do exist, I can't see anything about concurrency design. If thinking about safe concurrent writes is wrong, then I don't want to be writing code for you...