>You are being paid, in part, for your capacity to be frustrated and stressed for hours at a time
As an ex-employee, I can confirm that being frustrated and stressed for hours at a time accurately describes the engineering experience at Scale – a large part of it in fact
I can offer you this: I did a couple rounds of interviews with them, and the hiring manager's pitch to me regarding the type of hard problems they had to solve included "MongoDB keeps crashing because of bad queries."
Because it means the challenges you'll face are not because they're solving hard problems, but because their code is awful and their development process is broken.
To be honest isn't that the case at almost every web-focused startup (i.e. almost all tech startups)? We like to tell ourselves we're like NASA rocket scientists but almost all tech challenges the typical software engineers faces (even at places like google/amazon/facebook/etc) are mundane and not require PhD level understanding of computer science.
When I interviewed at Google a decade ago I asked the interviewer that directly and he admitted most of the work will be maintenance & that sort of challenge (he was a former CS professor).
This was for natural language processing at search so very much the foundation of google's bread & butter/cash cow (pick your favorite metaphor) and something you may think requires pretty sophisticated work. But I guess by then a lot of the fancy work has already been done & I'd have been one of 1000s of programmers working on it.
I mean in the sense that people assume they are doing hard stuff compared to your run-of-the-mill Java EE/.net companies servicing "boring" computing needs of industries like insurance/banking/logistics/etc (which outside of silicon valley is where most - or at least a lot of - software jobs are at).
Yeah, that's pretty much it. They didn't say "MongoDB keeps crashing because it can't support the load we're putting on it right now." They said it keeps crashing because of "bad queries." Leaving aside the fact that no database worthy of the term should ever be crashing due to a "bad query," there's also the fact that a very important component of their architecture (a data store) isn't even close to being reliable. Yet, somehow, the name of the company is "Scale.ai?" It's absurd is what it is.
This article is has a lot of good stuff to chew over, but I couldn’t help but get distracted by the second sentence: The phrase “Scale is growing incredibly fast right now” has to be up there with “Valve releases Steam” in terms of “you named your whole company just so you could make this joke?!” moments. Excellent work, well done.
Damn, let the paint dry before sharing your experiences. I'm not saying they aren't valid or good observations, only that the short/no time reflection undermines credibility.
Always fascinating to me that people will take raw information and just be like "Wait, don't make it visible. Make it invisible."
Like, you can always assign whatever coefficient you want to this. It is like wholly to my advantage to encourage people to make information available. Like, why would you want the counterfactual universe where you can only see how people feel 5 years in. Ideally, for me, I could query at any given instant.
I think if we're speaking honestly, we're only going to have so much patience for the author's blogposts. We're not going to upvote updates for 6, 12, 18, 24 months at a hypergrowth startup. So I do think it makes sense to prefer a source filter.
"It’s okay if you don’t have a lot of context on a pull request. Try to contribute one useful thing. One of the best ways is to check it out locally and take the feature for a test run!"
Since I work in the space I'm biased, but having to pull someone else's code locally to test out their feature is such a non-starter for me. If your company is in hyper growth mode (or even if it isn't) and the engineers don't have their own dev environment or better yet an ephemeral dev environment to allow others to test run the code, the company is hampering their product velocity.
Obviously we cannot ignore the fast that Alex was just 19 when he started Scale, and he is able to talk with world leading experts on AI. That doesn't seem like an easy job. Although Scale earns its money from human workers who clean and annotate data
This appears to be a job ad. Looks like an interesting place to work.
I wish them luck. That’s not a bad list, but it’s probably an environment that I’d find uncomfortable, personally. I work extremely quickly, but in a very different way.
> It’s important to make people feel at ease right away in an interview. Relax and show interest in them and their story
This never happened to me, even once, while I was looking (I stopped looking, some years ago). In fact, several companies started off, being quite disrespectful, right off the bat. It was almost universal, and convinced me that it’s de riguer HR policy, these days. I assumed that it’s because it’s a strategy to keep the applicant off-balance, and in a subservient position, right from the git-go.
For myself, as a hiring manager, I made sure to be polite, respectful, and interested, all the time. I felt that it was important to make the applicant comfortable. It usually paid off, as they let their guard down, and often volunteered a great deal of information that they would have otherwise kept to themselves. Even if we didn’t offer, I wanted them to think of us in a positive manner.
I think a lot of these lessons learned apply to any larger organization (> 10) that has well defined internal structure with an eye to scale or has already scaled. I recently transitioned to working more within a larger organization (with a lot of healthy cross-team collaboration), and had to learn and relearn many of the same lessons.
Place a lot less trust in this or any other company than OP seems to. I've heard troubling things about both the founders and I wouldn't touch the company with a ten-foot pole, even though it's clearly doing well.
As an ex-employee, I can confirm that being frustrated and stressed for hours at a time accurately describes the engineering experience at Scale – a large part of it in fact