Recent submissions

Comment · 2 years ago
Sure thing! We hire primarily out of SF, NYC, and Seattle -- in-person has boosted our productivity and been a lot more fun for us! Transparently, we have made a few exceptions, and are not entirely opposed to more, but it's really the exception rather than the rule.

We are in-office 3 days a week, so there is some flexibility built in there, too.

Comment · 2 years ago
Opportunistically chiming in :)

I lead engineering here at Retool -- reach out to snir (at) retool if you're interested in learning more! We're hiring across several key roles, including AI, performance, our core products, and infra.

Comment · 4 years ago
Hi all, I'm Snir -- I lead engineering here at Retool.

I wanted to follow up on the above. Solving the round trip problem David mentioned above involves multi-region for our entire backend, inclusive of our DB. This is definitely a priority and something we plan on having by EoY.

Comment · 12 years ago
Sure, in some sense :) This model exists under a number of names: Pesero, Jittney, Monit Sherut (to name a few). That said, it's not just an app that we've built. It's a system that can make dynamic decisions about which routes merit being paired together, and communicates with our drivers about any changes that need to be made to the current route. Of course, we take on-road safety into account, and so changes are only made while the vehicle is stationary.
Comment · 12 years ago
Absolutely :) There are lot of systems like this that we took as inspiration. See my comment below on how we formalized this type of transit, and built something that can make more objective decisions as to whether the pairing "makes sense."
Comment · 12 years ago
Lyft pairs one passenger (or equivalently, one party) to one driver. We've built a system which will actually take your route into consideration, and pair you with additional passengers that are en-route (relative to you). In other words, your ride is shared with other people heading in the same direction you are.

While are drivers are for-hire at this phase (in order to provide a reliable and available supply-side), there is much higher utilization in the car as multiple riding parties are paired to it.

EDIT:

I see the question was changed slightly. Higher utilization makes all the difference. Our current public transit system is just as you've stated: a vehicle being shared by "more strangers" (in your own words). We envision our system creating a completely adaptive and dynamic transit grid, which lends itself to predominant way in which people get around in the future.

Comment · 12 years ago
Response has been really good (a subjective answer :)). For more objectivity, we've received ~40 leads for one CL post, and got about 10 leads in small little twitter campaign ($5 ad).

People seem to be genuinely excited about collaborative consumption, and we enable route-sharing (I hesitate to use "ridesharing" since the term has become overloaded and isn't accurate to its origins). Passengers are sharing their ride with others, and that's new in the on-demand era.

There have been plenty of mental models built up with the one-to-one sector though (one driver, one customer), so we have seen the need to start explaining from the ground-up, so as to articulate the differences.

Comment · 12 years ago
We haven't, but that's a great idea. There are some limitations that tether us to cities (so networks like SamTrans in Palo Alto aren't ideal), but AC in the East Bay would be an excellent fit.

Thanks!

Comment · 12 years ago
We've actually been working on something like this for San Francisco (and we plan to expand onwards after operating here): http://www.takehitch.com

The municipality tends to work a little slower here (chatted a bit with SFMTA in the past), so we're starting with a model that just focuses on private cars. But the fundamental point--dynamic re-routing to create custom routes where people can ride in the same vehicle--is very much in the spirit of what we're doing.

We're still in a pre-launch phase, but check out our iOS app: http://www.takehitch.com/download

Comment · 13 years ago
Glad you like it!

We dont have any revenue sharing relationships in place with any of the services we link out to. We don't have any plans to monetize at present either. We found ourselves switching out between these different apps whenever making transit decisions, and decided to build it out. If we observe operating costs getting too high, we might seek out those relationships.

Comment · 13 years ago
Sure thing. Just dropped you a line.
Comment · 13 years ago
Strange. They should be distinct. I'll look into it.

On the biking side, we're considering looking at joins between biking and other modes of transit. So for example, you could bike an extra mile and get on a different, more direct bus/train (assuming it can carry your bike).

Glad to hear you like the app :)

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton