nulptr

The +12 there is so that % works correctly (ie the number never becomes negative)

Hard y… yt = white

One way is querying the dht

If each command would only be executed two communication turns in the future, and a communication turn is ~200ms, isn't there ~600ms of lag for each command?

> For RTS games, 250 milliseconds of command latency was not even noticed -- between 250 and 500 msec was very playable, and beyond 500 it started to be noticeable.

The article mentions this as well, so was ~600ms latency just expected?

Why doesn't it work to execute commands _one_ communication turn in the future?

Yeah, this is irritating... one workaround for this is to do:

(in the context of walking a tree...):

    fn get_depth(root_opt: &Option<Box<TreeNode>>) -> usize {
        let root = match root_opt {
            Some(root) => root,
            None => return 0;
        };

        1 + std::cmp::max(get_depth(root.borrow().left), get_depth(root.borrow().right))
    }

Some starter code for each language that prints hello world would be nice. ALso, you can look to coderpad.io for other features to add for fun.

important to note that there's little choice for men or women in the "happy multi generational example"

were you applying for a data scientist or software engineer position?

Ahh yes, that's very clever. Thanks for sharing :)

I think I found a way to do it with ~8GB. As you mentioned you only need 2^30 tries due to birthday paradox.

But, instead of using a hash table to store (seed, hash) pairs, we can just use a list of only hashes. To generate the next hash we use current hash. i.e. next_hash = hash("example.com/" + string(int64(cur_hash))). So now, we just store 60-bit hash values which takes up 2^30 * 60 bits = 8gigs.

The only other problem is detecting if a hash already exists, which I think can be done using a space efficient probabilistic hashset like a bloom filter (and when the bloom filter says the hash already exists, we do a linear scan to find where it exists and we have a possible collision).

I have a question about how you generated collisions.

If each seed is a 32-bit int, and each hash is 60 bits, then you'll have to store 92 bits for each (seed, hash) pair.

With 2^32 (~4.3 billion) (seed, hash) pairs, you'd need 2^32 * 92 bits ~= 50 gigabytes.

But you mention only needing 8-12GB. Is my calculation wrong, or have I missed something?

I don't think it's just about solving the problem.

It's also about: - how you convinced yourself and the interviewer that your solution was correct (essentially an informal proof of your code)

  - how you test your code after you finish coding

  - what clarifying questions you asked to tease out a concrete question

  - what edge cases you thought of and how you handled them

  - how you handle bugs if they appear in the code

  - what solutions you presented and what their tradeoffs were, and why you decided to use a particular solution

  - whether your code was idiomatic

  - whether you used clean abstractions

  - maybe also comments and variable naming

... and probably others I'm missing.

I don't deny that interviewers have their biases, but I would hope that your interview performance is the major factor in whether you received an offer. There are plenty of people at Google and Facebook who haven't majored in CS at a top school.

If you accuse someone of theft, shouldn't the burden of proof be on you?

Also, if two people make a bet, and one person wins, is that theft?

because "ssdf" is a string but B("asd") is user-defined sum type.

So in the original example, you can't unify "ssdf" and the int 33, but in the re-written version B("sfd") and A(33) have the same type and can be unified.