Does it fit? Can it scale? How fast? How many? As algorithms are to coding interviews, this topic is to the design interview.
The book Programming Pearls has some great information about this topic. It’s a skill you should really use up front in designing code, and systems, hence the need for a separate topic.
You should first take a look at Latency Numbers Every Programmer Should Know, as well as the posts by the Google Director of Research (Norvig) on the same topic. You probably want to vaguely memorise the orders of magnitudes of those numbers. Remember it’s acceptable to round in an interview to make the math(s) easier.
- While you are there, you should also check out how to write a spell checker.
For the networking among us, these posts were nice:
64b packets, you get
14.8Mpps, means that you have:
- 100 MHz == 10 ns => 6 cycles
- 200 MHz == 5 ns => 13 cycles
- 1 GHz == 1 ns => 67 cycles
- 3 GHz == 1/3 ns => 201 cycles
That is not many cycles to do something useful with a packet… and that’s assuming you used something like DPDK to move the data nicely into the cache for you.
Think about what you are currently working on, and see how it applies. In the design interview post I’ll cover some more examples.