I was only there in 2022, but at that point there were in fact three or more monorepos (forked roughly based on toolchain - go and scala in one, primarily Ruby in the one detailed here, and there was one for the client stripe api libs that was JS only. There may have been more.
I just killed Reddit off my home screen after a decade of usage because of a totally different bullshit growth hacking thing - they have started injecting their “recommended” subreddits into my swipe stream.
I have thumbs downed every single recommendation they’ve ever put in my scrolling feed, and now am being forced to consume absolutely random subreddits that their models have decided I’m super interested in because at some point in the last ten years I clicked through an r/bestof link.
If you click the three dots on a recommendation you can select "show less like this" and you won't see recommendations from that subreddit. Also, there is a setting in user settings to prevent recommendations from subs you don't subscribe to from appearing at all, but I would give the algorithm a chance since there are interesting subs you probably aren't aware of.
Also, I wouldn't call making recommendations in home feed a growth hack, fwiw.
The key to Mastodon isn't to follow other people but to follow hashtags so they are in your news feed, and to use hashtags everywhere in your posts and comments so other people can find them.
This is very on point. We have platform and product in entirely different reporting structures that meet just below Sundar; this leads to hysterically different cultures. My team is trying to straddle the product/platform divide right now and it’s a constant learning experience.
A recent example: someone asked me for my team’s planning schedule, specifically when we figure out what we will be doing for the next six months.
My only response is “we don’t do that here”; my team has to constantly juggle projects to load balance downtime on projects (most of our work is very sinusoidal in how much time it demands in a week), and we pick up new ones that are important enough to add to the load from time to time.
The platform folks set out in December last year with a mission for all of 2021; the design is flexible, but they know exactly what the goals for their year are.
When one team has projects that take an arbitrary amount of time to “get right”, and the other has more reliably predicted cycles that just depend on coding output, things get a little hairy. Mostly just takes a lot of empathy for the folks on the other side, though.
I do platform, I have a rough idea of what I need to accomplish in a year, in two, and reasonable definition of where we'll need to be in the next 5 to 10 years.
The plans move all the time, but we have them there. We usually plan rough deliverables one to two years in advance. Detailed plans cover usually one to two quarters.
Yeah; my product team will get wildly different priorities over the course of a month as execs spin plates, PMs and managers scramble around, and we nail down what our next round of experimentation will involve. On top of that, relying on A/B testing for all decision making means you’re liable to discover at any point that there’s a totally different piece of software that you should have built instead.
My old gig was at Lawerence Livermore (home of Edward teller); there’s a photo of the sedan test with a few lab engineers posed next to it in the building that they interview new comp sci hires in. One of the senior engineers I was on an interview panel with told me all about Plowshare; weird to hear it from someone who wasn’t on the project.
Timezones. It’s hard enough scheduling meetings across multiple timezones (and boy are there a lot of meetings in FAANG), but going more than +/- 6 is a huge pain (I meet with east asia and europe on a fairly regular basis).
I'm sure there are more, but these are the ones that I've worked with in the past. European climate research agencies seemed to have their act together a lot better than US ones; before I left the industry, they were much further on the path of moving computation to the commercial cloud (instead of trying to keep up in the supercomputer arms race, which always seemed like a losing proposition to me), and I think ML has been increasingly integrated into climate models as a way to approximate complex dynamical systems.
In terms of which of these labs had their head screwed on straight from a technical side, it was probably KNMI / Met Office, followed by Max Planck and then IPSL.
It’s L4 as of like a year ago; also going up to L5 no longer has promo committee per-se, but instead is a PA meeting between leads who hash it out, and the manager is much more involved.
Yeah, but one of the main roles of pretty much every government is regulating what is sold in their markets.
(Were this a less autocratic regime,I would have said "governments are just people", but I take your point on the government of SA being largely disjoint from the citizens)
It's actually a reference to the USB-C ecosystem for the laptop line; Marco and his cohosts on the Accidental Tech Podcast have burned a lot of time griping about the state of connecting things to a laptop. Not so much time on the head phone jack, which was mostly a no-op for them (since it was paired with the airpods).
The front-end interviews at Google are about half algorithms and half details about how web front-ends should work, be structured, web technology problems, browser performance, etc. It's an entirely different interview track from General SWE.
Tell the recruiter you're a backend developer, and are interested in one of those positions instead.
The backend interview lets you choose whatever language you want. You'll be asked algorithms, distributed design, code quality, and data-structure questions.
Generally speaking, if you focus too much on a programming language / stack, it comes off as a sign that you're not a good fit, since you emphasize programmer skills, but they're looking for engineers. Except for particular roles, like front-end dev, where they're looking for programmers with experience in the technology stack itself.
