658 karma · joined May 18, 2009
[ my public key: https://keybase.io/mateolargo; my proof: https://keybase.io/mateolargo/sigs/ezV7MpDdq7S6s_6glV8gcvTMINrpTfCYIXwBIWpxuNQ ]
YC Badge: 0x0fa3d26951e11fb68e2d93fce3fef214060facc8
Work at a Startup serves primarily as a matchmaker for potential employees and founders and isn't directly involved in facilitating visa sponsorships or other details of employment. While YC advises our companies on how to best navigate and obtain visas, they are still ultimately the responsibility of the founders/company.
Startups are an increasingly popular place to work in the tech industry. At the same time, the most common problem founders need help with is hiring people. Work at a Startup is a new way to help solve this pain point for both parties by connecting people interested in working at startups directly with the founders of the 1100+ active YC companies by completing a common application.
This the next iteration of the "Work at a Startup Day" idea that YC started hosting way back in 2010 [0][1][2]!
For now, Work at a Startup is targeted at software engineers who want to work at US-based companies since that’s the most common need of YC companies. We will be expanding to other roles and countries once we've validated the product for applicants and founders.
[0] https://news.ycombinator.com/item?id=1346103
There are a lot of mentions of deterministic builds, but that is already very achievable with pip-compile (part of pip-tools) or just pip freeze.
The grouping functionality allows you to have just one requirements file instead of one per environment (i.e. production, test, development, etc) which is mostly just a personal preference IMO. This isn't particularly compelling to me, but that could be because I'm already used to the traditional "pythonic" way of having one file per environment. Using the -r command within a requirement file allows one to recursively include other requirements files to avoid duplication of common dependencies across environments.
The difference in syntax between traditional requirements files and Pipfiles is indeed pretty large. The Pipfile syntax is quite a bit more verbose which I'm personally not a fan of, but this will come down to personal preference and what one is familiar with.
It's unclear if Pipfiles as proposed here is meant to include the dependency resolution functionality of the pip-compile command provided by pip-tools. That is a very critical step as vanilla pip makes no guarantees about respecting version pins of nested dependencies; only that some version of a nested dependency will be present but not necessarily the one intended.
Another big unknown that others have asked about as well is how Pipfiles can be used to manage requirements for a library in a way that allows other libraries/apps that do not use Pipfiles themselves to still list said library in their requirements.txt.
Apologies if my comments comes across as overly negative or dismissive; I applaud any effort to improve the tooling around Python dependencies. But as someone already familiar with the Python/pip ecosystem, it's not clear how this would improve or simplify the solutions that are already out there.
Edit: On a second read, it's less clear if header based routing is actually available yet...
If I'm remembering correctly, one theory is that their canned food was tainted with a bacteria (not terribly uncommon for the time) that caused mental issues which triggered the bizarre chain of events of them leaving their shelter is various states of undress.
[1] http://www.missedinhistory.com/podcasts/the-dyatlov-pass-inc...
I suppose the same could probably be said for any intro course or just college in general...
Crocodoc (YC W10) founder here. When our company was acquired by Box in 2013, we launched a new set of developer APIs on the Box platform for anyone (even those who don't use Box itself) to use for converting documents to HTML. We're now powering apps from LinkedIn to CoTap to the newest version of WebEx.
We've also open-sourced one of our biggest projects (https://github.com/box/viewer.js) and are expanding into developer experience as well.
We're looking for frontend and full stack engineers to join our close-knit team and help us push the limit of what browsers and mobile devices can do. (Fast, pixel-perfect rendering of documents using just HTML, SVG, and CSS turns out to be really hard!)
We're also building out a developer experience team and are looking for someone who is passionate about UX, APIs, and making developer tools easy and fun to use.
Drop me a note if you're interested at long@box.com or matt@crocodoc.com
Maintaining a good company culture™ was very important to me and the other founders and we were very aware of how much our early hires would contribute to it. An important part of that culture was only hiring the best and smartest people (yes, it's cliché, I know). It did not even cross our minds to hire an operations manager (or any other role) who could not understand and comfortably explain our product, for instance. I think that did a lot to set a tone that no one should have lower expectations set for them nor was somehow in a "second-class" role.
P.S. In my defense, it was darn good beef jerky.
EDIT: English is hard.
[1] You said Bay Area, but lets at least try to compare apples to apples.