There is a counterpart company in China called FlashEx that is doing pretty well (just raised Series D in 2018) right now, focusing on same city on demand shipping.
Similar to Gojek and Grab in SE Asia. They're basically bike couriers but on mopeds. You give them an object and address, and they'll take it there. Faster than the mail, obviously; and much more convenient than navigating through SE Asian traffic yourself.
For the language I love its concurrency model; creating thousands of "processes" at your PC/laptop is no problem. Message passing over shared memory also makes your distributed program easy to reason about. When talking about Erlang, you can't avoid OTP. It makes creating fault tolerant system at ease. Putting these two pieces together you have a very scalable fault tolerant distributed system.
I don't like the syntax of erlang though. And the missing of macro makes me switch to Elixir.
For one thing, how many drivers they have matters. More data might produce better estimated ETA (at least Uber use the data from the drivers to predict future traffic congestion, etc.).
Another thing is how well they control supply and demand. Say Uber has 10x drivers than Lyft, what if Uber has 100x consumers than Lyft? Uber likely has to surge at a very high rate, and the consumer can't afford a surge might go to Lyft instead. Since Uber can't control well how many total consumers they have at the moment without surging, one realistic alternative is to just reduce the number of Lyft drivers, so Lyft have to charge higher rates as well.
Here Uber doesn't just want more consumers coming in, because even less consumers is better than more consumers come in initially and can't afford a surge and then have to turn to Lyft.
So to sum up, in the end, Uber have to recruit more drivers (hey, they even just opened API for their product) or cut the number of drivers from Lyft (through alluring them). You can't blame Uber on that, it's the competitiveness of this market.
As the ban of ZenMagnets's primary opponent was in 2012 [1], and the government seemed to want to ban ZenMagnets [2], I find it amazing it is still out here in the business two years later and with a record sale $700k last year (a jump from $50k in year 2012).
The context for these coding-challenges is they are the type for algorithm competition or white-board coding interview.
Back then when I was still looking for job, I was asked this question by a startup. I gave out this hashset solution and was quickly asked if O(1) space solution was available and then asked to implemented it.
If the space restriction is not an issue, I would definitely go with the method you suggested. Way more succinct and easier to follow.
a) takes O(n*lgn) time; the method in post uses O(n) time
b) use extra memory; the method in post uses O(1) extra memory
c) have logical error: the problem asks to find the first missing positive (in range [1, infinity)).
So firstMissingPositive([4,100]) should return 1, instead of 5. But the problem is not stated in the post, so let's assume you are implementing the first missing positive in range(A[0], A[-1] + 1) for sorted(A), your code does not handle corner case well.
For example:
a) your firstMissingPositive([100]) gives ValueError: min() arg is an empty sequence
b) your firstMissingPositive([]) gives IndexError: list index out of range
It is attempting to write three-liners that seems to solve the problem, but it is far more important to solve the problem in time and space efficient way. At least, it is important to handle the corner cases well.
def firstMissingPositive(A):
try:
for x in range(1, max(A)+1):
if x not in A: return x
except: return A
def firstMissingPositive(A):
try: return next(x for x in range(1, max(A)+1) if x not in A)
except: return A
Thanks for the ValueError tip. I added it as well as a TypeError just in case the input comes in as a string. My skills are beginner level at best, tips like yours help a lot!
