Thr author could have skipped a step and formatted using tags instead of markdown and published the html directly, with zero need for any generator. Using scp and html, like it was 1998.
^ those are the job reqs for the central recruiting across the company. Thanks 'CFShopify' for posting. =)
I'm a Dev Manager in the Shopify Fulfillment Network. If anyone is interested in talking about the culture or what working at Shopify is like, feel free to hit me up on twitter @tmarthal or email tom.marthaler@shopify
> seem to have hit one of these areas of toxicity yourself
Have you considered that the original poster's experience is actually the norm and that your experience is the one that is the anomaly? I was 1 for 2 in organizations with shitty leadership, and the organization that was run properly had zero open headcount. Everywhere people are hiring into is not one of the "good ones".
Check out the old-fart tool, 85% of the company has been at Amazon for 3 years or less. Do you think that if the normal/average organization/team was a great place to be, that there would be so much attrition?
But hasn't Amazon expanded massively in the last 3 years? I'm not sure how meaningful those numbers are unless the employee count is relatively static.
I have considered it. I don't see the pattern widely, and I'm watching for it. I've seen teams implode because of it, and other toxic patterns, so it's not that they're not there... they just seem to be in the minority. There are teams I won't send friends to work for, for sure.
I've been doing software development for nearly a decade now and I've seen 0 teams implode. Nothing I would call a "toxic pattern" springs to mind either. If you've seen multiple occurrences of both at Amazon and think it's an ok place to work then I think you've just normalized the dysfunction.
> collision probability of 1.3 percent, with the two satellites coming as close as 190 feet (50m)
LEO orbits have speeds around 7.8 km/s (rounding up to ~8000m/s for quick calculations) - this avoidance detection is saying that the two satellites both traveling at 8000m/s would be in the same 50m box at the same second.
A quick calculation shows that the collision avoidance is operating at least the millisecond level to predict this collision (50m/(8000m/s) ~.005 seconds.
One thing someone once mentioned to me is that space is big and things travel fast. It's hard to believe that the two satellites (most likely each <1m in diameter) came "close" to colliding, when a half second later they would be 8000 meters apart.
Starlink satellites are a bit bigger than that from what I can gather on google at least.
> came "close" to colliding, when a half second later they would be 8000 meters apart.
So is a bullet if it goes through you. Space is big but the orbits these satellites operate in aren't as big as space itself.
Why does it matter if it's hard to believe anyway, they gave a figure of 1.3%, which is pretty low anyway, and they didn't do it on the back of a napkin.
> By that logic, surely every interview practice is justified?
In a sense, they are. As long as the interview practice is well understood by the applicants, it only leads to filtering the applicants that cannot pursue the requirements for that practice. Granted, the FAANG interview process and filtering only works because the SWE jobs are desirable enough.
I understand that the required practices and filtering also lead to a certain type of applicant. This is the main fault of the system (the lack of diversity potential).
The median tenure of engineers at Amazon is 1 year. That means that the new engineers need senior and principle engineers to guide them on what tools exist. If an engineering organization happens to have strong senior Amazon engineers then they can guide their teams/org to use the tools that exist, because they do exist.
However, everything (and I mean everything) at Amazon depends on the team (and organization) that you land in. Some organizations do not have senior technical leadership; service ownership is handed off to teams without long tenured Amazon engineers so they do not get exposed to the types of tools to use (nor do these teams get time to discover, learn, and on-board to the tools that do exist). This is how an engineer can have the experience written about in the article.
The article is anecdotal, and definitely not the norm for the "majority of engineers"
Further down the article she mentions that she solved the dependency by "I ended up rewriting the Lambda in Java", noting that the use-case doesn't care about the known JVM warmup times.
The POM packaging and jar based deployment seemed to make the dependencies work.
I think what you're actually seeing is the output of a Kalman Filter temporal model. The zestimate is the mean of the filter output, but the error bounds of the filter are more important than the actual mean/reported value.
What happens is that the model uses trends to extrapolate from each "real" data point (in this case, a house sale in your neighborhood). The problem is, and what Kalman Filters help manage, is the uncertainty propagation between each house sale. When it has been a long time from when a sale has occurred, it is unclear what the real/actual price is of a home. This means that on the estimated price the error bounds are large, and zestimate still just reports the mean value of this huge uncertainty.
What then happens is that a house is sold in your area, a new data point is recorded, and the filter re-adjusts itself and collapses its uncertainty/error bounds in the time of that measurement around the measurement. And you get correction. This is why the "old zestimate" is updated.
I wonder if AMP isn't just an open source/mobile friendly version of StumbleUpon. Not sure if anyone remembers those SU banners at the top of most blogs, trying to get more in-site clicks from deep linked articles.
