heh, I used to work on the data team at Shopify. I built something similar to search internal dbs for secret santa gifts based on some weird criteria. Scraping might have a large margin of error because a lot of products tend to be ephemeral.
> Because of this, there’s more deviation from what was planned and designed to what was shipped and there’s less alignment across teams, so it’s harder to coordinate feature development.
Asking as an outsider, won't shipping a lot of things in this environment lead to some suboptimal product state. I'm used to coordinate > build > learn > iterate > ship; which although slows down gross feature development, tends to prevent the 60-80% of experiments that don't work from getting launched.
Does removing meetings to optimize throughput of feature development not get us into some feature factory mindset? This isn't binary btw, but I think moves thinking more towards a build mindset vs a solve problem mindset.
I mean, imagine what housing in Toronto would cost if they didn't build those 100K+ condos? Pricing is composed of supply and demand, and the article is saying that holding demand constant, increasing supply lowers prices. Adding a marginal unit to the housing stock kinda has to result in lower or equal prices in the static case.
Toronto is growing insanely quickly, and supply can't meet demand. New cities are great, but a large number of people want to move to big and established population centres.
1. That is a very deterministic statement
2. This is a part of the process, not the entire process. There are still technical elements tested during the interview.
3. The signal that they are looking for, but do not tell candidates, is a story about overcoming obstacles.
What I will say about the lifestory, is that it aligns with the skillset required to do well in a corporate environment. Namely telling stories, being relatively interesting, and having some ability to sell yourself and your accomplishments (in addition to being technically competent which is tested elsewhere).
In addition to being a highly volatile source of revenue to the government, you would have to give tax breaks for unrealized capital losses out of fairness; which would introduce a ton of complexity.
I'm on a data team of 10, and after about 6 months of onboarding we have permissions to push directly to main pending passing tests. We generally do this for small changes, or changes where we are the context owner. With the caveat that reviews happen after the code is deployed, and usually within a few days.
Personally, I like the process. It allows us to move quickly, and focus on blocking changes. We can still get reviews prior to pushing code if it is sensible (for large changes), but most (80%?) changes tend to be quite small.
Looking at their past 10-k, cost of revenue is ~$1.8B which includes infra costs. As these are self hosted, infra costs are largely going to be fixed; with a smaller component scaling with usage (things like electricity and maintenance).
Usage going up, and taking a 50% haircut on revenue would make quite the dent in cash flows.
But then this has the impact of reenforcing model predictions (unless controlled for). This lead won't convert based on the model, so I won't spend time with them or give them any preferential pricing, so the lead doesn't close (and the converse is true).
This isn't a pure ML problem, and without "treatment" data I'm not quite sure how the blog is adjusting for customer propensity towards an outcome :/
Fast didn't make it to market. I would see two ways that Bolt would be a success:
1. Grow with Big Commerce
2. We see a hard push to headless commerce, and Bolt becomes the "Shopify of Checkout" or something similar specifically for the headless use case.
Neat project though!