2 ms·
Meanwhile in real life it's mostly - better error handling (you don't want your batch to fail because 1 of 1 million items had an issue, usually) - sane retry
by nijave 2y ago
Meanwhile in real life it's mostly
- better error handling (you don't want your batch to fail because 1 of 1 million items had an issue, usually)
- sane retry/timeouts
- fixing bad db queries
- vundercind 2y ago- cache more. Even if it’s kinda dumb caching. - everything becomes stream processing when you really need performance and/or your dataset gets big enough.
- dbcurtis 2y agoFor some values of "real life". I don't mean that sarcastically... I mean that for many production environments (like customer-facing retail web site), I agree with you. But that isn't the entire world. I've spent a lot of time doing hard realtime code. Often on limited-resource systems. (Oddly, its more difficult to get it right on resource-rich systems...) In the realtime world, it does require a certain amount of savvy to pick an optimal trade-off of run time, memory, and I/O. Hard realtime forces you to learn complexity analysis or die. You also have the luxury of a clear, bright benchmark for "good enough to ship", which shuts down a lot of purely philosophical arguments.
- hot_gril 2y agoI prefer to ask questions that are easier on the algorithm side and have time to see how well the interviewee covers edge cases, handles errors, shows me that it works, and writes tests. Our company's work is more about reliability than efficiency.