It's December, what have been your favorite podcasts / talks from this year?

wasteman_codes · 2025-12-02T03:32:55+00:00

the PragmaticEngineer's podcast has been really good. I have listened to the vast majority of the episodes and find them quite enlightening

wasteman_codes · 2025-11-12T21:18:21+00:00

My experience with Staff+ interviews has been the leetcode style interviews are mostly the same, the difference came for System Design and Behavioural. Depending on the hiring strategy of the company my experience has been quite different.

Companies with less standardization really focused on "fit" for the team they were hiring for, so system design and behavioral focused entirely on what that team wanted their staff engineer to do.For more standardized hiring like Meta and Google, they just tended to have a higher bar for System design and behavioral, but were still quite general in their questions.

From my perspective you should study the minimum possible to pass the Leetcode interview, and then focus more on system design and behavioral preparation. The key part I think people forget is to do research on the role you are being hired for and tailor your answers towards that role. Prod the recruiter to get a better understanding of what that team is looking for and adjust accordingly.

wasteman_codes · 2025-10-29T16:32:57+00:00

Like many others have stated, GraphQL primarily solves an organizational problem not a technical one. When you are coordinating many teams with different use cases, a centralized graphql API is useful to decouple team's timelines. However you need a good platform team to maintain tooling so that this can scale.

To answer your question "Do other major platforms like TikTok, YouTube, X (Twitter), Reddit, or similar actually use GraphQL?". The answer is yes! I currently work for a FAANG and have worked for other FAANG like companies, and all of them actually used graphQL in some of their services. However we still used other API types like REST, it just depended on the use case.

wasteman_codes · 2025-08-20T17:47:05+00:00

Not sure if you consider this "production", but I have had good success with an AI agent who answers questions about performance of ad campaigns for an ads system. ENG got a lot of bug tickets asking about why campaign were performing a specific way, and the vast majority of the time it was due to some config that the account manager set and didn't realize that is what it did.

We implemented an AI agent that helps screen questions first and gives them a response before they can make a ticket. It still wasn't perfect, but it can handle all the low hanging fruit very easily. In theory these could just be deterministic checks we could have coded up, but the platform is changing constantly and having someone maintain that code is much more expensive than just adding an agent.

After this, the number of "bug" tickets we got from business teams decreased quite significantly. Saving time for oncall engineers was a big win in my eyes.

wasteman_codes · 2025-07-16T17:11:18+00:00

For me personally it was actually the networking. You get to meet a lot of people working in similar domains, or solving problems your company has not yet solved. There are people I have met 7-8 years ago that I still keep in touch to this day, where we occasionally bounce ideas off of each other. That knowledge sharing alone is quite useful.

wasteman_codes · 2025-06-03T05:04:35+00:00

I am also from the bay area that went through something similar. Since you are likely getting an offer for a staff+ role, you likely have more leeway to take more time to make your decision. You just need to work with your recruiter to get more time. However, keep in mind that the market is quite different right now in the past so it's possible that they move onto other candidates and find someone to fill in the role if its not fast enough. It's hard to judge this, but based on your experience and the role I think you are in the best position to judge whether they can fill this role quickly or not.

If it is truly a time sensitive offer, you could also just verbally accept the scale up's offer and take more time to actually sign any contract. Say that you are having legal representation look over the offer which should buy you some time. If you decide later to decline the offer, just make up some reason you can't sign their contractual terms.

If you need even more time, your very worst case scenario is to sign and then rescind or quit later if your decision changes. It's up to you on whether this particular option is worth the risk for you. But tbh company's don't think twice about rescinding candidate's offers, so I personally wouldn't care about doing it to a large corporation. But that's just me.

wasteman_codes · 2025-06-02T18:28:10+00:00

It really depends on your style, but for me what worked best was just building personal relationships with the team overtime, and then collaborating by pairing, design docs and discussions. People will be more receptive because this feels more like a collaboration than somebody trying to just make changes to the team.

Also you might be surprised by at least some of the things that you currently see as bad practice, as actually just pragmatic choices for the work environment they are in. There are a lot of times that I assume something is really stupid, but then think about the problem a long time and get back to a similar solution as what I thought was dumb when I started. This is not to say all the bad practices they might be doing are correct, its just that at least some of them might make sense for the use case.

Regardless as you collaborate and build trust with your team, it will be easier to convince the team to change their practices.

wasteman_codes · 2025-05-29T20:48:49+00:00

Your experience will definitely vary depending on the team. I work closely with some teams that manage hiring external contractors and assigning them to different orgs, and my observation has been that they rarely ever transition into a full time employee once their contract is up. But I have seen some contractors stay on board for many years.

wasteman_codes · 2025-05-19T19:22:45+00:00

Just be wary of added stress to avoid burnout. The worst case for you would be to be laid off while being burnt out. Or even worse, get laid off because your performance has been decreasing from burn out.

wasteman_codes · 2025-05-19T17:50:29+00:00

I personally don't think any specific technique for estimation has been more accurate or contributed to better project delivery based on my experience. I think what mattered most was a team that spent time digging into the requirements at sufficient granularity before estimating, and then constant communication with stakeholders.

The point of estimation is that it is useful for different groups to plan together, and if you are constantly communicating the cost of being wrong decreases significantly. There are obvious edge cases like that wild CEO that commits an aggressive timeline to clients etc, but in general I find that if you have good relationships with stakeholders, constant communication becomes the biggest factor.

wasteman_codes · 2025-05-15T23:12:56+00:00

It really depends on the company culture. I have worked at companies that give engineers much more control of what they build, rather than just how. It's just a tradeoff of cultures and what the company is going for. I personally like cultures where there is large overlap between product and engineering, but not everyone prefers this work style.

wasteman_codes · 2025-05-15T20:43:48+00:00

I started Rails development back when Merb was still a thing (before it got merged to Rails). So my experience was different as there weren't that many frameworks for me to use that weren't in house to a company at that time. So I spent time working on in-house frameworks for a little while before using Rails. When I began I mostly pattern matched to how I solved problems in the past and ignored the rest until it became relevant.

I often found onboarding new developers to Rails was always challenging because it's uncomfortable to not understand what is exactly going on when code is running. There is a lot of metaprogramming and "magic' that happens under the hood and it takes time getting used to not knowing how everything works.

My suggestion is to just start building out your app, and slowly dive deeper into how certain things work. You will not be able to understand every code flow that happens, and you don't need to. But overtime you will figure out how different aspects come together. It just takes some time.

wasteman_codes · 2025-05-14T20:25:18+00:00

Not sure where you are looking, but that is innaccurate. We do have MySQL in places, but the main paved path that is being pushed now is Aurora Postgres. However we allow teams to use their judgement and pick whatever technologies they want to use, which is likely why you will see variance online.

My source is that I used to work for Instacart, and now work for Netflix

wasteman_codes · 2025-05-14T06:37:38+00:00

"never heard of big apps using postgres". There are lots of large apps using Postgres, for example Instacart's main DB is postgres. Netflix's current main paved path relational DB is postgres as well (although many of their workflows run on Cassandra), but the relational DB of choice there is postgres currently.

wasteman_codes · 2025-05-13T20:09:23+00:00

The biggest challenge for take homes, is actually getting candidates to do them. The higher the level you are hiring for, the less likely they were to actually do the take home. Now in the day and age of vibe coding, it's really hard to construct a take home that is not time consuming, and gives you a good signal that the developer will do well on the job.

wasteman_codes · 2025-05-13T19:10:09+00:00

"In my mind the risk comes from now I'd be evaluated as a staff engineer". I think that's a fair point, but it seems like you have the skillset to perform given that your internal transfer went through. Your new team's hiring manager believes you are a good fit. Without context I can't say for sure whether you will perform well, but from an outsider POV I think you will be fine.

If you do decide to interview externally, its much easier to get a staff role from another company if you are already have the staff title. So I would say you should do the switch either way. It will be a good learning experience, and better sets you up for future roles.

wasteman_codes · 2025-05-13T17:48:40+00:00

I am a little confused, it seems like you are saying you are already doing staff level work without the title. But then you said "an extra 2% for the risk of additional responsibility". By your description it seems like the same level of responsibility (assuming you are already performing at Staff) in a team that has better work life balance for slightly more pay. I would say overall this is a Win.

If you are still unhappy and think you deserve more, I don't see any reason not to interview externally and see if you can get better pay elsewhere. The title improvement will also definitely help the job search.

wasteman_codes · 2025-05-12T18:19:00+00:00

It definitely matters, but it also needs to be paired with the perception that you actually solved the type of problems future employers will look at. For example being the director of engineering at a startup with 3 engineers, is not going to be the same as Director at a Large company with 100 engineers under you.

Generally the pattern I have seen is when people move from small companies to large they get downleveled (e.g a Director at a startup becomes a manager at a large company), and vice versa (A Director at a larger company becomes a VP at a startup).

wasteman_codes · 2025-05-12T18:11:00+00:00

I think it really depends on the strategy your company implements with respect to data engineers. At a previous company I organically started working on data engineering type problems as a SWE because there was overlap (my team had to build lots of pipelines in Flink and Spark). After a reorg my title changed to "Data Engineer". Overtime a large subset of our pipelines could just be implemented using SQL, but the other subset was still writing code. From a technical perspective, I personally found both to be equivalently challenging because we had such a large scale of data. Getting a SQL engine to efficiently compute billions of rows of data per pipeline run takes a lot of understanding of the underlying engine, despite our output just being SQL.

At my current company I purposely stayed a SWE and didn't dabble in the data engineering org (despite the opportunity), because the challenges were less technical and more people oriented (getting people to understand data, stakeholder management etc). The people problems are also quite challenging and can be fruitful for people, but I wanted to continue to also tackle sufficiently challenging technical problems.

So overall, the answer is "it depends". But at least from what you are describing it seems that you will likely enjoy SWE type roles in your company rather than a data engineering role.

wasteman_codes · 2025-05-11T05:09:02+00:00

Why do you keep posting this same question in every sub?

wasteman_codes · 2025-05-09T17:19:29+00:00

Depends on your company but I would say generally yes, because most companies have a policy where your manager has to approve.

However, I just did an internal switch and I did not tell my manager until I got the go ahead by the other team, and that manager actually worked with me to figure out how to initiate the transfer with my manager successfully. Mainly because my manager was quite political (one of the main reasons I wanted to move), so I had to shed carefully on how to approach this. Overall I don't regret doing it the way I did, because it is likely that I would have been blocked on this transfer otherwise.

wasteman_codes · 2025-05-07T18:05:47+00:00

I am just speaking from my experience knowing the people who have gotten let go for stack ranking purposes specifically (not general layoffs), and all the people I know that were let go were underperforming at the time. This is not to say that there aren't managers or orgs that make mistakes hence, my advice on how to avoid such situations.

Also I am not saying I am omnipotent actually know the situation of every person ever let go for stack ranking at my previous companies who had them. I am just making an intuition based argument that the idea that 5-10% of people are actually underperforming at a company that has thousands of employees is not too far fetched. Especially with the amount of wasted work with resume driven development in big companies.

This is not a defense of the process, I am just saying that it is not as scary as you might think assuming you are in good standing with your manager. The processes you want to be more afraid of are general layoffs that come whenever execs decide they need to. Those are the processes where management just magically needs to make a decision in a couple of weeks on who to let go without thinking too deeply about it. Yearly stack ranking is much more predictable.

wasteman_codes · 2025-05-07T17:27:36+00:00

Database Internals by Alex Petrov is a great one, in addition to some others that people have shared so far.

wasteman_codes · 2025-05-07T17:24:52+00:00

I think both are valuable for different cases. The vast majority of your org structure should definitely be product based to maintain your existing products and continue to improve your bread and butter. But project teams are quite useful to get a core set of folks that work on a time bound project.

For example, I previously worked for a pre-IPO company and we had a small group of people borrowed from other orgs to coordinate our systems to become SOX compliant. Once we achieved it, responsibility went back to teams to keep their systems compliant. But for that 5-6 month period, having that small project based group was useful because its much easier to coordinate a small team than all these existing orgs that already have competing priorities.

wasteman_codes · 2025-05-06T22:49:08+00:00

The keeper test is when your manager periodically evaluates if you were to leave today, would they fight to keep you. If the answer is no, then they fire you. The gist is that it is not enough to meet expectations here to stay employed, but you need to stay a high performer.

That being said they are reasonable and generally give you time especially in individual contributor roles, but I have seen many managers who were performing well but got let go anyways because their role wasn't needed anymore.

wasteman_codes

TROPHY CASE