Ask HN: Joining Big Tech in One’s 40s
Hi HN — I'm 43, and at a bit of a crossroads. I sold my share in a company last year and have been taking time off to figure out my next move, and while I've mostly done startups my whole career, I am considering going for a job at a big tech company (FAANG/Lyft/Stripe/etc.). Does anyone have any experience doing this? I can still keep up coding, but should I do that, or try for management? What skills should I brush up on particularly? Mostly, I am a bit fed up with the stress and uncertainty of startups and looking for something more stable, at least for a while.
202 comments
[ 2.9 ms ] story [ 350 ms ] threadIt's okay to be disrespectful. It's not okay to preface that disrespect with an overtly false disclaimer.
Perceiving my comment to be disrespectful, I think, is a part of the larger societal problem that exists today; namely, of people being overly-sensative.
Friend, I will gently invite you to toughen up.
You can define "disrespect" however you wish. It matters little to the recipient who undoubtedly feels slighted at the "arrogant" characterization.
I can only say this man. Your comment history on HN worries me. It's very, very negative, and hear me out. I'm not putting you down, but when there is anger or bitterness in one's heart that hasn't been dealt with, it's easy to only see, or even create, negativity in life.
I don't want to argue with you. Just know that you can make a decision to root for others, uplift people with your comments on HN, and sometimes just totally pass up opportunities to argue and move on to a positive comment.
Jumping from argument to argument on HN will only create anger and hate in your heart.
I could be totally wrong. This is just my opinion. Regardless, I wish you the best man.
You did it again. Please, it's okay to put people down.
The remaining questions regarding coding vs. management or what skills to 'brush up on' are very person-dependent beyond general platitudes. Sure, discussions can be had, but it kind of depends on what he wants.
you need to disclose what was your role in these startups.
if you want to go back to coding at FANG there would be less ageism but it will still be there. Be sure to brush up your algo, data structure. I would suggest finishing a book of programming interview and you should be set.
I don't like this assumption: Some of the older engineers & architects I know are incredibly more adept at developing than management, and speaking with a lot of them, most are pushed into management roles instead of desiring them.
Big picture infrastructure
Big picture domain knowledge
Big picture risk management
Big picture release management
Big picture languages
Big picture frameworks
Big picture architecture
Big picture maintainability
Big picture knowledge sharing
Big picture build infrastructure
Big picture etc
If you have a GOOD senior, you will safe a lot of time on bs, and will make your junior devs shine like rockstars.
HN can't answer this for you. Which do you prefer?
Really love coding, really hate management: Apply for IC. Tolerate/enjoy management: Apply for management.
> I am a bit fed up with the stress and uncertainty of startups and looking for something more stable, at least for a while.
I think you have answered your own question there for the most part, and I don't think its too much to ask for a bit of stability.
Personally, I would advise you take some time to think about what areas & roles you enjoyed the most, as you're looking for something possibly long term, don't make it difficult `WORK`, instead make it something you enjoy.
Then you can dedicate your time looking for the projects/companies you really are excited about.
Sounds like a dream, but theres no reason why you can't suit yourself!
Best of luck!
PS: I don't think you should worry about your age, if thats why it was in the title; but if you're like me, over time I lose patience with people who wonthave a genuine discussion & be open to being wrong. But this is a maturity thing that you can asses at interview time I guess.
Those are the things I try to determine when I interview someone.
Consulting is nice because projects/customers come and go so every few months you're on to something different. Of course, consulting has down sides too but i seem to have a knack for it.
edit: reading some other comments I think it's easier to be an older IC at big companies than startups/small companies. But whether you should pursue a management track is a completely different question.
[updated] IC = worker with management tendencies but more technical knowledge.
[kept] Ok then. Helpful. Corporatespeak is often just jargon creation to exclude others for whatever reason.
[edit expansion] Worker who is not manager but has manager skills sufficient to orchestrate as needed to deliver a result in required manner. Knowledge level exceeds expectation normally associated with a classic "pure" manager.
Many software engineers (including myself) much prefer the IC route.
Ok I probably mangled this but IC just paid for itself in my mind via increased understanding, nuance and useful brevity.
There's also the verisimilitude that it can also mean an inferred ceiling. For example, Principal <whatever area> Engineer role[s] at Microsoft is [are] typically the highest that you can go - if you stick to the IC (read: non-managerial) track[s].
At least in the initial stages it seems FAANG companies at least are very good at ignoring age for applicants, later stages though are tougher when most people interviewing you are half your age.
It's a trade-off though, by choice I'd be programming most of the time.
That said, you should do what you want, especially if you have your nut already. Look for an outfit that really needs someone and is willing to look past age (or even sees it as an advantage).
Also, you may already know this, but big companies have their own problems. Unlike at smaller companies, these are deep structural or cultural issues you will not be solve. Instead, you have to learn to make the best of it and not let it get to you.
Only regret is that I absolutely under leveled myself (msft L64), and after a couple years getting dragged through a couple of reorgs, I still feel like promotion is a ways off. Most of my peer group is 10 years younger, and most ICs of my age group are at least two levels up. So wait for an opportunity at the level you think you should be. Don't let imposter syndrome talk you out of it or think you can make it up after you join.
But even still, I'm doing way better now than I was back in Michigan working for startups, even accounting for cost of living.
Also note the most challenging change for me was getting used to how little control of anything you have is. I really miss being able to basically decide my design and implement it against public well-known technologies. Now so much of it is calling around, trying to figure out how other teams are doing things, coordinating with them, ensuring backward compatibility with a million old things, blah blah blah, it's much slower and less interesting. But, still worth it....I guess. (second-guessing myself now?)
And don't let imposter syndrome weaken your resolve on that salary if you're coming from somewhere with way lower baselines. You don't need to be a super hero at any level short of "partner" level. You'll just end up with a lower leveled job than you should.
My experience at msft in a nutshell. They pay very well and their name brings prestige, don't forget that when you second guess yourself!
Mostly algorithms and system design interviews. I thought I did pretty well (something like 3 very good interviews, 1 good, and 1 ok). In both cases, the conclusion was that my results were good enough for an L4 position, but they wouldn't hire me for less than L5. (Why not, I'd be happy as an L4...). Also, I found the interview process pretty random and arbitrary. One company praised my algorithmic skills, while the other said that I did very well on system design). They encouraged me to re-apply.
I'm not concerned about the actual job, I don't feel less capable than my 30 year old self. I'm more knowledgeable, and I have more experience with human interactions.
The interviewers all told me that you don't have to be a manager if you don't want to, and that good developers were always valued, regardless of their age. I don't know how much of this is true though. I can't help thinking that my age had played against me in the final decision.
The interview process is a pain. It's very random, it takes a lot of time preparing (some people literally spend months working full time). The things they ask you have very little value besides getting you a job. At least, it's kind of fun to work on these leetcode problems, but after 200 hundred variations of BST and dynamic programming exercices it starts to get old. Also, if you already have a demanding job (and maybe a family), it's hard to find the time to practice.
If you spend enough time preparing AND if you aren't stressed out during the actual interview, I think you can pass with reasonable probability the algorithm interviews. I found system designs a little more random. My question wasn't in the "syllabus" they provided me. Also, as an older programmer, there may be many things that you knew a few years back. You're disadvantaged compared to a younger graduate.
Can you elaborate on this? Were you interviewing specifically for L5 roles? I wonder if years of experience or even achievements can be used against a candidate by raising the bar so to speak. Maybe one is a L5 at their current company but only a L4 elsewhere. As long as you can contribute at whatever level is appropriate for the given company I don't think it should be held against the candidate.
A year later a different recruiter from the same company contacted me again to ask me to re-interview. Then he contacted the recruiter from one year ago to see if I had to retake the initial phone interview, or go directly on site. After discussing with her, he told me that they don't have currently an L5 position open, and that he would be contact me again in a few months (which he didn't).
Just because someone with many years of experience levels lower than typical doesn’t make them a bad person or even a bad hire. But it does make them a more risky candidate to hire (more likely to be "middle of the pack"; less likely to be "undiscovered superstar"), and so some companies choose to pass.
(I’m arguing that this is rational, not that it’s right, fair, or morally sound.)
If you don't have that endless stream, you are more likely choosing between "this candidate" against "no candidate" vs "this candidate" against "the next qualified candidate".
I don't see how this could be legal, even in an employer-friendly a nation as the U.S.
Sure, there are some outlier candidates who enter the field later in life as a second career. But for the overwhelming majority of candidates, "years of experience" is a very thin proxy for "age". I can understand requiring a minimum YOE, but there's no reasonable justification for a maximum.
Failing to have grown skills and project scope to L5 level after extensive time in the industry could be interpreted by some as poor motivation or career growth planning - their thinking is that if you've been doing the same thing for years elsewhere without growing, you'll tend to be trying to do the same things for years there without growing.
An individual might be trying to get into a FAANG in order to get experience with technically complex projects of a certain scope. A lot of roles out here at non tech or smaller firms are just building and maintaining simple CRUD interfaces. The business domain may be complicated but the tech execution is probably not. I thought the algo gauntlet was a equalizer where exceptional coders could clear the bar regardless of education or work history.
From an interview point of view, they're probably looking for examples of that independence and self-motivation (ie, not just doing what someone told you to do), and also the step beyond just writing the code towards more holistic ownership (things like "created a new test harness along the way", "did a survey of developers", "made sure there was a killswitch", "created a rollout strategy", "convinced another engineer to share review and support responsibilities").
The projects I've worked on in my career haven't been considered in the interview process. They just expected better results on their standardized interviews (algo + system design) compared to a more junior candidate. I don't think the question they ask correlate at all with candidate experience, even for the system design part.
But overall, I think it's an imperfect but fair process.
Edit: I've now found levels.fyi - these are Google's internal progression levels.
Unless I'm missing some details, this actually sounds like age discrimination.
Wouldn't it be the same as not hiring a 30-year-old basketball player who is performing at the same level as a 25-year-old player?
It can be, and I've seen it. In general there is an assumption that people who come in at too low a level relative to their experience won't be happy and won't stay, so it's not a good idea to hire them.
Obviously some people are exceptions, but hiring managers will err on the side of caution.
https://leetcode.com/discuss/interview-experience/360829/ama...
One way to deliver that experience is in delivery management, that is, being responsible for teams that ship stuff.
Another way to deliver that experience is in people management. Not all companies equate this with the previous responsibility.
A third way in in a more nebulous “leadership” role that doesn’t have “manager” in the title, e.g. “Architect,” or “Principal Engineer.”
The latter is tricky, but can be a very good opportunity. My 2c on being in engineering leadership is that it’s best to think of yourself as a manger without authority, rather than thinking of yourself as an engineer with authority.
- - -
FWIW, I am 57 and a Principal Engineer with PagerDuty.
That's great, and resonates
If you're a senior enough person who doesn't want to manage people, you should think of yourself as a "know-how" (knowledge, experience) manager and find a role that allows for that.
As a technical lead (getting into my 40s soon) I try to think of myself as an chief enabler / support net: Let the team figure out implementation, support them as they go where they get out of their depth - and protect them from DIRECT trickle down BS/interruptions from management or clients.
This has worked pretty well for me thus far, but I've really got no idea if this is a solid approach or way of thinking.
I'm curious to know anyones thoughts?
I'm actually a Vice President without any direct reports. I'm on the same level as the head of software delivery on the organigram. See myself as chief enabler too. Fixing architects disillusioned designs and try to explain to developers how to implement these designs. Sometimes I dabble doing some POC. Good thing is that I don't have people management bullshit, downside is that this is my glass ceiling if I stay here :)
Im a principal at AWS. A coworker made a joke that resonated with me; a principal engineer is a manager without direct reports.
My job is twofold. Helping managers understand where to go. Helping ICs and teams to get there. I have no inherent authority and it all comes down to trust and influence.
That said there does seem to be a push to reemphasize the ‘exemplary practitioner’ aspect and scale back on the high level “architecture” and pseudo PM aspects that creep in with expanded scope.
In between and before those, I have worked at two startups and three other in-between (in size) organizations, as well as two non-tech giants, over the course of about 27 years now. Kind of takes my breath away seeing that last number!
As others here have noted, no matter where you work, one of the most important things is your manager. I've had good managers and bad managers, and my less happy time at the previous 'FAANG' was largely due to a bad manager.
Having said that, the department/group you're in is also important. I had a great manager at one of the large (but not giant) companies but the department had big problems. It was a relatively comfortable but in the end unproductive couple of years. (And also why I decided to move on relatively quickly.)
Re: skills to brush up on: honestly, I suggest just start interviewing heavily and use that as a template to figure out what you need to learn.
The big tech companies have the luxury of having tons of talented, qualified people trying to work there, and so structure the interviewing process to be biased toward turning away qualified people rather than accepting unqualified people.
That means that the interview process can be pretty strenuous.
Re: trying for management: I was a manager briefly, early on in my career, and decided that I was never going to do that again. I was relatively good at it, but I didn't like it, so all of my roles have been technical, though of course a lot of the best things I've accomplished involved large quantities of 'soft', non-technical people work.
Re: fed up with uncertainty. Yup, I totally get that, and it's the main reason I haven't done more with startups. I value my personal/family time too much, and always have.
Feel free to contact me directly: diederich@gmail.com
Best of luck.
One of the biggest pitfalls of ICs regardless of age (but I see it more as some get older) is the inability to break free from the past. If you cant learn, or refuse to accept, anything new have no use for you. Tech is changing constantly and if you can't tout something you are looking forward to and just constantly looking back on that one project you did and using that same method/tool/tech it really makes it difficult to envision.
There are IC roles that are "lead" but not management which our company calls "Principal" consultants - that seems to be the latest term in the industry that everyone is going with to denote someone at a high level of expertise who contributes at somewhat of a manager level but not necessarily of people just of projects but is still more of an IC than a project manager.
I say this because that is personally a cardinal rule of mine, and I've never heard anyone contradict it -- hiring a manager comes with inherent risk, and you significantly add to that risk by hiring someone that hasn't done it before. If you want to try out management, you should first get a job as an individual contributor somewhere and then move into a management job in that company. They will know a lot more about you from having worked with you and you will know a lot more about the team, the company, etc and have a much higher chance of being successful.
This is really a two-way street, you are much more likely to be successful this way as well. The interview process is simply too artificial to get a good read on how someone will do as a manager when they don't have previous experience.
This is my experience too. Companies don't like hiring managers without at least a little experience, and often are resistant to hiring first level managers at all. Instead, they look for "senior IC, but manager material" candidates, and extend an IC offer with a loose expectation of becoming a manager in a year or so. It's not an explicit role you can apply for, but you can target it by applying for an IC role and keeping any leadership and team-focused experience visible on your resume and during your interviews.
As I get older, this is the bucket I tend to get put in during interviews, and then after joining I decide if I want to be a manager this time around.
Thanks.
If you don't have enough engineering manager experience, you can generally join as an IC (with a full IC interview loop) with a view to converting to manager. You may have additional discussions or even interviews around management as well, especially if converting to manager is something you identify as a career goal (as opposed to an option).
Converting to manager from an IC is generally pretty easy if you've shown good aptitude for leadership - the larger companies generally find it a lot easier to hire ICs than good managers externally, so internal conversions are necessary to keep up with demand for quality management attention on teams.
Often, you'll still have a coding (or other technical interview) and a system design interview, and a probably very similar general "people skills/career" type interview that an IC gets. But instead of another one or two technical interviews, you'll have another one or two manager-focused interviews (how to build teams, how to run projects, how to grow individuals, how to navigate a particular scenario).
At Google, the bar is that you are expected to be able to contribute as an equivalently senior IC, but will be expected to use those skills to inform how you do manager stuff.
So you will definitely get technical questions, the type of which will vary slightly depending on which level of management you're interviewing for. But they will be legit technical questions, like solving a graph theory problem or designing a distributed system.
In addition, you'll also get explicit sessions probing you on your leadership style and management fundamentals. Standard behavioral stuff.
Non CS background doesn't seem to matter as much as actual leadership experience afaict. Formal leadership roles seem to be weighted more strongly when considering your level, but you do seem to get some credit for informal roles too. I'm not super sure on this point.
I think it'd be hard to go directly as an external IC to a manager role. That's not a risk I'd personally want to take if I were the hiring manager in that situation.
If it helps you calibrate, I had about 6 years experience as a line manager at other companies, and I was considered for (and hired as) a line manager. I was never being considered as a 2nd level manager of managers.
hth.
Also is the technical bar lower? And do they care at all about having done business school?
"Tell me about a time you had to resolve conflict between two engineers on your team."
And then a bunch of follow-up questions. "What went well/poorly about that", "what would you do differently next time", etc.
This is why I think it'd be hard to go directly from an IC role to a manager as an external hire.
FWIW, I think that hesitation would apply at any company, not just Google. In my last company, I myself was in charge of hiring other engineering managers, and I can tell you that I didn't even consider any resumes unless they called out some sort of lead role.
If they were an actual manager, i could skip directly to the behavioral questions. If they were a tech or project lead of some sort, I did a lot more probing on the exact scope on how much they dealt with people, what they were and were not responsible for, etc. before even getting into the behavioral stuff.
Managers are hugely influential in any org and hiring is an inherently risky activity. You want to minimize risk, not increase it by hiring someone who's never done the actual job before.
Back to Google, I'm not sure the technical bar is lower at all. I got literally the same questions that any senior IC would get, just fewer of them in order to have time for the manager sessions.
No idea whether recruiters care about business school. From my own personal observation, b-school can prepare you to do some analytical stuff, like cash flow analysis or broaden your knowledge base by reading M&A case studies, but nothing in there prepares you to be in charge of running a team with actual humans on it.
If an inexperienced manager is hired by the tech company, the blame falls on the tech company's hiring practices when things don't work out, not the applicant. People will always want a big raise or promotion.
My dev friends over the last 10+ years have included people who made a management/dev track career decision and anecdotally speaking, those who chose management have earned more and seemed to have more employment stability. In a couple of cases, I have friends in my personal network earning 3X a senior dev salary managing dev teams.
Personally, I decided to stick with the dev track and have been somewhat dismayed to find (after 10+years with one employer) that I am often pulled into decision/management-type situations but am consistently evaluated as a lower-level employee because "coder." It's even more annoying when I chat with my peer group who made the mgmt track choice and I find that the overlap between what I do and they do is actually very large.
I think this is highly relevant. Traditional companies have a historically inherited structure where the talents to 'do things' are relatively easy to come by, allowing management to accrue larger influences and hence compensation with the organization. The practice has a lot of momentum as you would hire the same managers even for a software business, they'd come from one of these places.
The growth of FAANG and other new tech companies threatens to end this by driving up the scarcity of engineering talents, while creating an entirely new management class that used to be engineers. While they do make more than most engineers in those companies, they take on highly technical decisions that management in traditional industry mostly refrain (drive & initiate vs select from n things).
My suggestion for someone with a lot of experience is to focus more on networking your way in to the company than on skills brush up. Find contacts at the company(s) you are interested in and try to set up direct meetings (in person, video conference) to find out more about positions, responsibilities, etc. at that particular company. Each company has their own unique philosophies and growth paths for individual contributors vs. eng. managers, so I don't know that there would be one generic piece of advice to follow.
Feel free to reach out to me at <username> @ gmail if you would like to talk more specifics.
But if I go full-time manager, I don't know how easy it would be to flip back to dev / IC.
I am an IC so I make sure my code is top notch, which means I need to LC for weeks before I'm ready for the onsites.
You mention "trying" for management. If you haven't previously managed people, then you probably won't be able to get a good SDM role directly. Instead, your best path would be to be hired as an SDE, demonstrate strong managerial bones (mentorship, communication, process orientation), and then transition to SDM after a few years.
If you've mostly been an engineer, then you may want to learn more about what's expected from different levels of engineer so you can determine, realistically, where your experience will be sufficient, and where there will be gap.
This is very true. No company I’ve interviewed with so far was willing to hire a manager who hasn’t previously managed people.
> Instead, your best path would be to be hired as an SDE, demonstrate strong managerial bones
I’ve tried this strategy a number of times and I wish it was that straightforward. Usually, even internal management roles are set aside for people who have already managed people before. So, you’ll take the time to be an outstanding IC, develop credibility with the team and good communication skills, focus on process building... then finally the workload grows to the point where you need more than yourself and you think “now is my chance!” You go to your manager and propose to hire a few people under you and SURPRISE he already hired an experienced manager who will have three reports including you! Bummer!
I'm currently at a FAANG and it is that straightforward. You don't just say, "hey, I should have people under me" but you do say that you're interested in managing folks some day. The company even offers a specific development track and training for people that want to do that.
That's also how I got into management at a non-FAANG company. I was hired as an IC, but indicated that my desire was to be a manager. I eventually became a VP.
Obviously every place is different, but you do need to make your desires known.
>What's the bar for being hired as a FAANG engineering manager?
In my past cycle I interviewed at, and received offers from two of the FAANGs. Past Engineering management experience was required and experience managing other managers was definitely a big plus. I think it's that latter bit that really makes a candidate very attractive since there seems to be high demand. A history of strong IC experience and technical leadership was also required.
I didn't have FAANG experience, but did have significant startup experience and a clear career progression, culminating in a few years at larger (>10k people) companies. One benefit of startup work is that the majority of my past experience is being the primary architect & owner of complicated production codebases and systems. The larger companies provided an opportunity to show how I was effective working cross functionally and getting things done in orgs where I was not in the chain of command.
So, tl;dr: is that strong IC background plus a few years of management are required, but specific types of experience can make you more attractive.
FWIW I've been both an IC before and have steadily moved to CTO at my current startup. I come from a non traditional background (non CS) but had several leadership roles there.