Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

San Francisco, CA - Onsite or Remote - Shyp

Need to mail something? Request a pickup in the Shyp app, we'll pick it up from you, package it, and find the best deal out of UPS, Fedex & USPS to get your items to their location safely, cheaply & on time.

5 server-side engineers are serving operations in 5 cities. We just raised $50m and we're looking for engineers to help us grow.

Lots of interesting problems to work on, including:

- Dispatch and demand prediction - recently we announced we're making all Shyp couriers full time employees, http://blog.shyp.com/shyp-ceo-note/

- Standardizing shipping options and warehouse flow

- Scaling engineering - bit.ly/1fZsGG7 for example

Some of the benefits of the job:

- No getting paged in the middle of the night! Open hours are 8am to 8pm.

- Whatever laptop setup you want, and $400 a year in travel credit.

- Postgres and all timestamps are UTC

- Everyone leaves the office at 6pm sharp.

We'd love to talk to you! You can't waste our time by getting in touch. We'll answer all your questions and tell you a little more about what our interview process looks like.

Please drop me a line - burke@shyp.com, or check out our jobs page - https://shyp.com/jobs

Re: Remote opportunities - We are super interested in hiring great people who can't move to SF. We believe our processes can support remote work, but we understand this is a hard thing for us to assert with confidence. That said, we are extremely interested in building remote-work processes that scale - let's talk!

Not looking, but based in SOMA? You might be interested in our lunchtime tech talks - ping me, burke+talks@shyp.com.



"- Postgres and all timestamps are UTC"

+1


What's the stack like?


Javascript, Postgres, some Go (hopefully more Go soon). Redis for background job processing, though it hasn't been very reliable and we're investigating alternatives.


We pushed tens of millions of jobs through Redis/Resque daily with no issues. We had other instances receiving 30-50mbps of increment and set operations 24/7, too.

I'm curious what problems you guys are running into. Redis has been one of the best and most reliable pieces of software I've ever used.


hey! thanks for the reply. I'm sure it would be fine if we had it configured correctly - the issues we're seeing are a) unexpected behavior in the queue/worker library we are using, b) it was installed before most of us got there, and we don't understand the failure modes, and c) we don't have good visibility into the state of the system when it fails.

I have full faith in Redis as a tool, and I'm sure there are reliable queue/worker libraries that work with it but we don 't have one of them. even with a reliable datastore you need to make sure you're not dequeueing things twice or putting things back on the queue or suddenly having your workers stop processing things - we've seen all of these, and like everything, it's been tricky to balance "rewrite the entire thing" vs. "make it good enough & focus on delivering business value".


Thanks for the details. That balance is tricky to maintain. I've inherited my share of bad codebases at startups. :)


By Javascript, do you mean node.js?

Interesting about your Redis issue. I've found it to be reliable. Could you email me? (check profile) I'll try to help troubleshooting. The job sounds interesting, but troubleshooting is more fun. :)


Yes, he means node.js. (I also work at Shyp)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: