IMO as someone who has done hiring at a FAANG and many other companies, short answer is no, if anything it's the opposite. As long as you hit a sweet spot of staying at each place for at least 9-12 months with no gaps in between jobs--in reality, this means "it doesn't look like you were fired"--switching jobs not only makes you look more motivated, it also gives you a wider breadth of experience to draw from. A senior engineer at Amazon for 8 years knows how to do things the Amazon Way. A senior engineer who was at Google, Meta, Netflix and Amazon for 2 years each knows how to do things four ways, and as long as they can intelligently compare and contrast the way those four companies operate and the pros and cons of each, would be an extremely valuable asset.
The only time this would maybe not apply is director/VP level roles, though if you're switching at that level you presumably have a pre-existing relationship with someone near whatever role you're trying to move into.
" 9-12 months with no gaps in between jobs--in reality, this means "it doesn't look like you were fired"--switching jobs not only makes you look more motivated, it also gives you a wider breadth of experience to draw from."
Fuck HR. 12 months is nothing for actual deep learning. I've seen job hoppers come through my company and it's obvious most of them don't get very deep in the work and just move on instead of becoming a real expert in the system. It's one thing not to hold it against them, but it's something else to say count it as an advantage at such short intervals.
For general software engineering roles, like senior and below, 12 months is plenty of time. Good employees, in my experience, can reach full productivity in ~3 months as long as the company isn't a total mess. This isn't to say they're total experts and know all they need to know about the technology/domain/etc., but it's enough time to pick up what's needed to be a productive contributor.
Eh, I haven't seen it. Maybe my company is a mess. Usually they think they know what they’re doing and can contribute on delivering individual tasks. But it seems they lack the background on the strategy, business acumen, and reasoning behind the technical architecture. So yeah, they're productive in the role, but they probably haven't learned enough of value to significantly grow and bring thought leadership to their next role. Especially regarding longterm implementations of their designs/actions since theyre just onto the next thing.
as an EM, 12mo is too short and I will pass them if i see 3+ of those in their career (say 10yrs). why would I spend my resources to train you for a couple of months and you leave me in another 6-8mo. it will take a senior dev at least 3-4mo to be fully productive. In your example, you are effectively doing a temporary hire for 6-8mo.
I can't imagine it would be too much, depending on how it's worded it could show that the applicant has a 'wide range of experience'. Plus I kind of wonder if HR would already take that into account, it's not just software engineers and salespeople doing it, it's everyone, HR and Execs included
I think big companies (with recruiters) no, they just want to hire people and keep their jobs. At smaller companies, where non-recruiters are screening resumes, I think yes, but only if it's extreme (like 2+ jobs per year for several years).
OP learned the skill of starting up, running and selling a business while taking 30% paycut (and a huge risk tbh). He now has much bigger career paths open to him than "Senior Software Engineer".
> Contact us to opt out. If you want to exclude your Customer Data from Slack global models, you can opt out. To opt out, please have your org, workspace owners or primary owner contact our Customer Experience team at feedback@slack.com
Sounds like an invitation for malicious compliance. Anyone can email them a huge text with workspace buried somewhere and they have to decipher it somehow.
Example [Answer is Org-12-Wp]:
"
FORMAL DIRECTIVE AND BINDING COVENANT
WHEREAS, the Parties to this Formal Directive and Binding Covenant, to wit: [Your Name] (hereinafter referred to as "Principal") and [AI Company Name] (hereinafter referred to as "Technological Partner"), wish to enter into a binding agreement regarding certain parameters for the training of an artificial intelligence system;
AND WHEREAS, the Principal maintains control and discretion over certain proprietary data repositories constituting segmented information habitats;
AND WHEREAS, the Principal desires to exempt one such segmented information habitat, namely the combined loci identified as "Org", the region denoted as "12", and the territory designated "Wp", from inclusion in the training data utilized by the Technological Partner for machine learning purposes;
NOW, THEREFORE, in consideration of the mutual covenants and promises contained herein, the receipt and sufficiency of which are hereby acknowledged, the Parties agree as follows:
DEFINITIONS
1.1 "Restricted Information Habitat" shall refer to the proprietary data repository identified by the Principal as the conjoined loci of "Org", the region "12", and the territory "Wp".
OBLIGATIONS OF TECHNOLOGICAL PARTNER
2.1 The Technological Partner shall implement all reasonably necessary technical and organizational measures to ensure that the Restricted Information Habitat, as defined herein, is excluded from any training data sets utilized for machine learning model development and/or refinement.
2.2 The Technological Partner shall maintain an auditable record of compliance with the provisions of this Formal Directive and Binding Covenant, said record being subject to inspection by the Principal upon reasonable notice.
REMEDIES
3.1 In the event of a material breach...
[Additional legalese]
IN WITNESS WHEREOF, the Parties have executed this Formal Directive and Binding Covenant."
You missed the part where they say they felt like a rock star. Different people are motivated by different things. The key is, if you are very hard working try to channel it in a way that will actually benefit you.
Yes, don't let other people channel it towards themselves! You're in a company, - they will fire you when it becomes convenient to do so - don't burn yourself out for them!
The biggest reason i've seen is because management hasn't prioritized it. It takes a few scars before understanding the importance of these tasks, pushing for them prematurely can be really risky. Letting stuff fail might be a better path for consensus.
Yes, the people who set the priorities have to feel the pain in some way. If you as an employee want your boss to do something, you have to communicate it in a way that makes clear how the problem will affect what the boss cares about, not what you care about. Usually that means translating it into dollars or one of the boss's KPIs, like deployment frequency or support ticket volume.
Sometimes management doesn't prioritize problems because they're short-sighted or overwhelmed. But sometimes it's because they just don't understand how big a problem it really is, and the team fails to communicate it to them effectively.
For example, I've heard devs complain about how "the tests take too long." On one team I was on, a couple junior devs were complaining about this, but it turned out that "too long" meant five minutes. Could they be more efficient? Maybe, but getting that down to one minute would take a lot of work with no impact on our ability to develop and deploy multiple times per day. Once I showed them how to run their tests locally on just the files that changed, the problem was solved. But before that, they thought the problem was "technical debt," when really it was just a training issue. (Or, you know, a lack-of-ability-to-Google issue, but I'm trying to be generous.)
On another team, when I heard this complaint, the team explained that the full test suite took almost an hour, and flaky tests meant that they often had to rerun the tests or merge with failing tests. Needless to say, this had a clear impact on our ability to deliver rapidly with high quality, so this was something I prioritized.
Managers don't do the same work as you, so they don't feel the pain firsthand. And they're often not incentivized to care about the same things as you, at least on the same scale. As an IC, you tend to be focused on the next task at hand. The manager is thinking about their quarterly OKRs or whether the team is on track to meet their sprint commitment. If you want something to change, you have to connect the problems you have on the micro scale to the problems the manager cares about on the macro scale.
And if you can't do that, or your manager won't listen, then yeah: let the problems bubble up until the manager feels the pain, as long as it won't come back to bite you.
reply