Not restarting for over 2+ years is probably a problem, but not for memory leak issues. More realistically it's just going to be likely that those microservices will be difficult to start again if they ever fail - 2 years is a lot of lost institutional knowledge.

But blindly restarting each week isn't the solution - like Alex says, it's far more likely to be a band-aid solution over a less than ideal codebase.

In DevOps there's a saying that's relevant here - "Cattle not pets". Your microservices should be resilient such that you could kill any component and not experience any pain. This is particularly important in ecosystems like Kubernetes where pods can and will be rescheduled.

Netflix's solution to this was to implement a "Chaos Monkey", a service that randomly restarted production servers during the day to ensure their systems were capable of handling that kind of event.

I think a more holistic solution is to approach these microservices with the questions of why they're like this? Why does one require weekly restarts? Why has one continuously run for 2+ years without a single restart? Could this be improved or changed?

Senior DevOps Engineer

Scott Gardner

This kind of policy isn't uncommon, particularly in larger organisations.

I agree that it's unfriendly to workers, and it's a large part of why I didn't make an internal move at a previous employer.

Ultimately there isn't much you can do besides being upfront with your manager ahead of time so they hear it from you and not the hiring manager, and frame things less as against your current team and more how excited you are for the potential new role.

If you're seriously concerned that your manager may attempt to tank the interview or otherwise take action against you, it might be best to consider an external move instead of internally.

Make sure you reach out to your companies legal department (or whoever's closes) before you do anything official.

Once you add that company slide, you're presenting yourself as a representative of the company, and there's serious implications there.

I feel like the answer is contextual here.

AI pair programming is fundamentally a speed multiplier, it can pump out raw code faster than any of us ever can.

Which is great if you already know a language/system and just need to get the grunt work out of the way. But if you're following tutorials on something, that's not you.

Instead, focus on avoiding ChatGPT/Copilot for now - you need to learn the fundamentals at play here first, otherwise you can't even be sure if the code being hallucinated out is correct or even doing what you want to do.

Perhaps you could do this if you were interested in learning specifically about using AI tools, but if the goal is "learn how calculators are written" or "learn Go by writing a calculator", using AI will only hurt you.

I worked at IBM across a couple of cloud/saas offerings for a little over 6 years, from 2015 to 2021. While things may have changed with the split of Kyndryl and Arvind replacing Ginni, from my experience (and from talking to various managers and VPs/Directors) this culture isn't completely unexpected. From what I saw, the specific management chain and location was far more impactful when compared to similar companies.

For example, before Kyndryl was split off, my team was interviewing internally for a role, and a common theme from applicants in GTS/GBS was extreme overmanagement, resistance to change/progress, and long hours/poor work life balance.

I don't want to say it's a lost cause. I definitely saw modernisation/adjustment success stories at IBM. I was actually part of one back when I was a grad! But I do think there's a lot of value in seriously evaluating what impact is possible before you require support from much higher in the company. Don't kill yourself trying to solve what you cannot fix.

Mid-Level Site Reliability Engineer at Ping Identity

It's important to keep in mind that Recruiting is a numbers game for the most part, and LinkedIn is actually set up with this in mind - Recruiters have access to things like templates and variable replacement to assist this \[1\].

Personally, I'll generally only respond if it's clear that it's not a templated/copy-pasted message. I've got an emoji in my linkedin name that effectively highlights a lot of automated messages.

1: <https://www.linkedin.com/help/recruiter/answer/a412196/create-message-templates-in-recruiter?lang=en>

I've found that it's useful to consider what you're saying and how the other people might be feeling long after the conversation is over.

Personally, I'm very much a story teller in conversations and it can be very easy to get into a game of one-upmanship without meaning to, where you've always got a or more interesting story to tell after theirs. Once or twice is okay, sometimes we just have interesting stories to tell. But the more it happens the more noticeable it also becomes.

After all, if a junior's sharing their story about finding and resolving a difficult to track bug, they probably don't want to hear you start running into a story about spending more time to find an even more difficult to track bug with bigger impact. Especially if it happens *all the time*.

Perhaps this (or something similar) is happening. It's not any single specific incident, it's the pattern that's causing people to feel like you're bragging.

As a general rule, you should always criticise privately and praise publicly. While you might not see offering help as "criticising" it's still better to assume that they'll take it negatively, particularly when they're still new and therefore getting the lay of the land and learning everyone's personalities/the team culture.

Tone also matters a lot here. Try and come across casually, blamelessly, and positively.

This is definitely something that you need to talk to your manager about.

Regardless of why they're proposing these projects, you need to get ahead of it and make sure that your manager and you are on the same page about this. It will be infinitely better for you if your manager believes you're trying to grow and learn, than if they believe you already know these things and just aren't doing them for varying reasons.

I think it's also interesting that you state you don't have *experience* with the projects, not that you *don't believe you can do them*. If you believe you could do them with the understanding that you'll be learning and therefore progressing slowly, it's entirely possible your manager is already working under that assumption.

Personally, this sounds like an almost *textbook* case of Imposter Syndrome, and talking with your manager about your concerns will greatly help you understand if you genuinely are out of your depth and there's been a mistake in the hiring process (*unlikely*) or you're under estimating your value to the team.

There's a lot of good feedback in this thread already, but I figured I'd explicitly say something: **There's a very high chance you're not the only person with this complaint**.

You haven't mentioned specifically how you're feeling discriminated against, but at a company as large as Apple it's probably safe to assume that there's other people like you (whether that's LGBT/Race/Religion/Whatever). Find people who fit the bill that you can trust with the conversation and talk to them. If you're not sure, just casually mention an example in conversation, e.g. "Yeah it's been a weird week, MANAGER said X in our 1:1" and gauge their reaction.

While I'm no expert, I think that it sounds like your team is going about it (broadly) in the right direction. Generally speaking, introducing more engineers and shifting the oncall rotations to geographical timezones (aka follow the sun) are the two most impactful things that you can do to reduce oncall stress outside of directly reducing the number of alerts.

Here's my thoughts:

**Bias towards experience, not training**

You'll want to bias towards getting engineers to a "hands on keyboards" stage as quickly as possible - i.e. actually being the primary contact for an oncall rotation. This is because training will only ever get you so far, real experience and ability comes from having skin in the game. First oncall shifts will always be messy/have mistakes, so this only gets delayed by having longer training periods.

**Shadowing then implementing**

It can often be difficult to properly explain/document how you found an issue or a bug, particularly when it might not be easily replicable. But you want to have this data for new engineers so they understand what led you to certain decisions when they get a similar page. So the solution is to have them shadow you - whenever you get an alert that's not just, pull the new engineer into a call, screen share, and begin to resolve the issue. Bonus points if you instead have them screen share and you tell them the commands to run - they'll remember these commands much better than whatever you show them.

**Pair new engineers up with experienced engineers**

Ensure that the secondary engineer is one that's already experienced/knowledgeable about your team's oncall practices, and then encourage the new engineer to frequently check in with the more knowledgeable one if they're not sure about anything. This way you can be sure they're running the right commands/looking in the right places, and correct them or readjust their approach as needed.

**Have new engineers write/rewrite the runbooks**

Chances are at least *some* of your runbooks will be incorrect - they'll be out of date, or operate under certain assumptions about the reader, like the assumption that the reader knows where certain passwords are stored, or what certain services are called. When you run into these problems with new engineers, provide them with the necessary knowledge (like the service name) and then have them update the runbook. This way, the new engineer gains a deeper understanding of your architecture through the rewrite/update, and you open up the possibility to find *other* problems with the runbook(s)

**In Short:** Think of this in the same way we think about development cycles - we always want to have the shortest time possible between development and getting the feature into prod, to better find bugs/iterate on the idea. Likewise, it's better to get new oncall engineers into the rotation ASAP, then resolve the problems that arise.