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.
[+] [-] guyzero|6 years ago|reply
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.
[+] [-] jamesrcole|6 years ago|reply
[+] [-] braythwayt|6 years ago|reply
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.
[+] [-] donavanm|6 years ago|reply
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.
[+] [-] dfsegoat|6 years ago|reply
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?
[+] [-] o_____________o|6 years ago|reply
That's great, and resonates
[+] [-] daxfohl|6 years ago|reply
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?)
[+] [-] o-__-o|6 years ago|reply
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!
[+] [-] derwiki|6 years ago|reply
[+] [-] cmsonger|6 years ago|reply
That said, I just went in cold. If you've been coding and are current in one of the 3 big interview languages (C++/Java/Python), and if you still understand your undergraduate level algorithms course and the corresponding vocabulary, then you know what you need to know.
Side note: A thing that no one told me but that I had to figure out on my own is that your technical writing skills are one of the most important skills to doing well at google. It was unironically said to me that the highest reward/effort one can do at Google is to write documents. The person who said it was correct about that IMO.
[+] [-] decebalus1|6 years ago|reply
> if you still understand your undergraduate level algorithms course and the corresponding vocabulary, then you know what you need to know
speaking from experience, this would not get you nowhere near the level you have to be for passing the Google interview (or any other FAANG interview for that matter). You need to study long and hard in addition to solving OJ problems and familiarize yourself with different problem patterns. Let me give you and example of what I got at Google: https://leetcode.com/problems/remove-duplicate-letters/ Solving this problem optimally with only what you remember from undergrad algo courses is impossible. You either need to have a knack for these types of challenges or solve enough of them to identify a solution pattern.
[+] [-] derangedHorse|6 years ago|reply
[+] [-] sdnlafkjh34rw|6 years ago|reply
--- Here's the actual PDF contents -------
Algorithm Complexity: ○ Please review complex algorithms, including big O notation. For more information on algorithms, visit the links below and your friendly local algorithms textbook. ■ Online Resources: Topcoder - Data Science Tutorials, The Stony Brook Algorithm Repository ■ Book Recommendations: Review of Basic Algorithms: Introduction to the Design and Analysis of Algorithms by Anany Levitin, Algorithms by S. Dasgupta, C.H. Papadimitriou, and U.V. Vazirani, Algorithms For Interviews by Adnan Aziz and Amit Prakash, Algorithms Course Materials by Jeff Erickson, Introduction to Algorithms by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest and Clifford Stein
● Sorting: ○ Know how to sort. Don't do bubble-sort. ○ You should know the details of at least one nlog(n) sorting algorithm, preferably two (say, quicksort and merge sort). Merge sort can be highly useful in situations where quicksort is impractical, so take a look at it.
● Hash Tables: ○ Be prepared to explain how they work, and be able to implement one using only arrays in your favorite language, in about the space of one interview.
● Trees and Graphs: ○ Study up on trees: tree construction, traversal, and manipulation algorithms. You should be familiar with binary trees, n-ary trees, and trie-trees at the very least. You should be familiar with at least one flavor of balanced binary tree, whether it's a red/black tree, a splay tree or an AVL tree, and you should know how it's implemented. ○ More generally, there are three basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list), and you should familiarize yourself with each representation and its pros and cons. ○ Tree traversal algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder traversal (for trees). You should know their computational complexity, their tradeoffs, and how to implement them in real code.
○ If you get a chance, study up on fancier algorithms, such as Dijkstra and A (for graphs). ● Other data structures: ○ You should study up on as many other data structures and algorithms as possible. You should especially know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem, and be able to recognize them when an interviewer asks you them in disguise.
● Operating Systems, Systems Programming and Concurrency: ○ Know about processes, threads, and concurrency issues. Know about locks, mutexes, semaphores and monitors, and how they work. Know about deadlock and livelock and how to avoid them. ○ Know what resources a processes needs, a thread needs, how context switching works, and how it's initiated by the operating system and underlying hardware. ○ Know a little about scheduling. The world is rapidly moving towards multi-core, so know the fundamentals of "modern" concurrency constructs.
● Coding: ○ You should know at least one programming language really well, preferably C/C++, Java, Python, Go, or Javascript. (Or C# since it's similar to Java.) ○ You will be expected to write code in your interviews and you will be expected to know a fair amount of detail about your favorite programming language. ○ Book Recommendation: Programming Interviews Exposed; Secrets to landing your next job by John Monagan and Noah Suojanen (Wiley Computer Publishing)
● Recursion and Induction: ○ You should be able to solve a problem recursively, and know how to use and repurpose common recursive algorithms to solve new problems. ○ Conversely, you should be able to take a given algorithm and prove inductively that it will do what you claim it will do. ● Data Structure Analysis and Discrete Math: ○ Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other companies because we are surrounded by counting problems, probability problems, and other Discrete Math 101 situations. ○ Spend some time before the interview on the essentials of combinatorics and probability. You should be familiar with n-choose-k problems and their ilk – the more the better.
● System Design: ○ You should be able to take a big problem, decompose it into its basic subproblems, and talk about the pros and cons of different approaches to solving those subproblems as they relate to the original goal. ○ Google solves a lot of big problems; here are some explanations of how we solved a few to get your wheels turning. ■ Online Resources: Research at Google: Distributed Systems and Parallel Computing ■ Google File System ■ Google Bigtable ■ Google MapReduce
● Development Practices and Open-Ended Discussion: ○ Sample topics include validating designs, testing whiteboard code, preventing bugs, code maintainability and readability, refactor/review sample code. ○ Sample topics: biggest challenges faced, best/worst designs seen, performance analysis and optimization, testing and ideas for improving existing products.
[+] [-] Diederich|6 years ago|reply
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: [email protected]
Best of luck.
[+] [-] yodsanklai|6 years ago|reply
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.
[+] [-] southphillyman|6 years ago|reply
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.
[+] [-] dominotw|6 years ago|reply
https://leetcode.com/discuss/interview-experience/360829/ama...
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] sulam|6 years ago|reply
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.
[+] [-] lostdog|6 years ago|reply
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.
[+] [-] syndacks|6 years ago|reply
Thanks.
[+] [-] heedlessly3|6 years ago|reply
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.
[+] [-] robdimarco|6 years ago|reply
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.
[+] [-] Rickasaurus|6 years ago|reply
[+] [-] tom_b|6 years ago|reply
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.
[+] [-] Aperocky|6 years ago|reply
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).
[+] [-] lvspiff|6 years ago|reply
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.
[+] [-] aspectmin|6 years ago|reply
I lasted 3 years and then got the urge to go chase my own thing again (ML/robotics consultancy), but most my friends (well into their 50’s) are still there.
Go for it.
[+] [-] harel|6 years ago|reply
Anyway, after my timeout I got back into contracting. First of all, I've never encountered ageism and my experience was always appreciated. It could be to do with my attitude, or maybe ageism is not a thing in the UK as it is elsewhere. I think attitude helps and if you come across as a friendly experienced person you will be able to get in.
My question to you would be why go for the "Larger" tech companies? Why not focus on established smaller companies? I personally equate those with start-up level stress but less ability to affect things. Again, just my personal perspective. Second point - do try contracting. It's quite liberating not being tied to a place in a long term mental-bond. The market is great for contracts (at least in the UK).
[+] [-] ping_pong|6 years ago|reply
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.
[+] [-] wonjohnchoi|6 years ago|reply
Reading some of comments in this thread made me realize that many people don't figure out what they want to do, even until 40's, so I feel better that I am not alone in this. I thank you all for sharing your perspectives with career. I will bookmark this page and read this whenever I feel lost with direction of my career.
[+] [-] nameseemslegit|6 years ago|reply
I have seen some people make the transition smoothly... others not so much.
[+] [-] czbond|6 years ago|reply
edit: I'm in Denver, and here senior leader positions are not too common.
[+] [-] sizzle|6 years ago|reply
You have an interesting background, would love to learn more about your career trajectory. Do you have a blog where you write more that you don't mind sharing? Feel free to email a link if you're up to it. (email in bio)
Thanks!
[+] [-] streetcat1|6 years ago|reply
Tech companies really care about your tech skills (assuming that you do not want to go to the manage route), so age should not be an issue. However, skills might be an issue. I.e. if you spent your career in companies that use tech, you might not have deep specialization.
Companies that use tech, are easier, which tends to bring less experienced developers, which usually are younger and might create ageism.
[+] [-] unoti|6 years ago|reply
The age thing wasn’t a problem for me interviewing for an engineering position. However, I had some difficult engineering interviews with senior and principal engineers. You should prepare hard to interview very well. The hardest part is convincing young senior engineers that you’re as good of a develop as they are or better.
[+] [-] sbussard|6 years ago|reply
[+] [-] bilekas|6 years ago|reply
> 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.