Ask HN: Joining Big Tech in One’s 40s | Hacker News Reader

Ask HN: Joining Big Tech in One’s 40s

441 pointskemiller184 comments

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.

View on HN

I was 37 when I joined Google in a senior IC role in 2008, so nearly my entire 40's. It's still work, there are still issues with coworkers and there's still stress compared to the startups I used to work at. The company isn't going to go out of business but you can still get a manager who doesn't communicate well and gives you bad performance reviews as a result. Google turns over more employees in a month than the entire headcount of some of my previous companies. And GOOG is a huge company - if anyone says it's either great or horrible that's probably true for them, but it doesn't mean much for what your experience is going to be. I honestly don't think that being young is really much of an advantage one way or other here - there are successful people in the 40's here, even ICs, there are a lot of new grads who wash out after a year or two and go elsewhere. Big companies have much more idiosyncratic tech stacks so knowing any particular technical skill isn't that huge a deal as we probably don't use it anyway. Know the basics, know how to write, know how to manage up.

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.

If anyone else isn’t familiar with ‘IC’, it seems it stands for “individual contributor” (as opposed to a role where you're managing others). Correct me if I’m wrong.

[was] IC =worker.

[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.

Not quite, the term IC also comes with connotation you don’t want to be a manager track.

Many software engineers (including myself) much prefer the IC route.

so... a not-just-a-worker who is manager level in terms of ability to orchestrate but is knowledgeable in excess of typical expectations for that of a classical "pure" manager.

Ok I probably mangled this but IC just paid for itself in my mind via increased understanding, nuance and useful brevity.

It doesn't imply "manager level". Anyone can be an IC at any level. It might imply "not on a manager track" but strictly just means "not a manager right now". Since it is the opposite of "manager" it might have all kinds of connotations due to being where that distinction is relevant, but the denotation is still just a technical role with zero reports.

>...but strictly just means "not a manager right now".

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].

It's an abbreviation. It's used to save time. I don't want to waste away typing Hyper Text Transfer Protocol.

You just did.

I didn't waste away this time, I'm still here. But next time I might not be so lucky.

Haha, thanks. Too much political investigation news for me these days. What the hell does working at FAANG in your 40s have to do with the Intelligence Community?

Anybody in their 40s or older has valuable experience above and beyond ephemeral value of “Hitting the ground running with Cabbage and Sprouts containerized with Cuper9s using ES2020 and JSxyz.”

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.

> it’s best to think of yourself as a manger without authority, rather than thinking of yourself as an engineer with authority

That's great, and resonates

Andy Grove talks about this in "High Output Management". He says there are two kinds of managers, "know-how" managers and "position" managers. Both have a certain amount of authority, and a successful technology company needs both.

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.

It's also been my experience as an engineering manager that it's best to think of yourself as a manager without authority.

> "A third way in in a more nebulous “leadership” role that doesn’t have “manager” in the title, e.g. “Architect,” or “Principal Engineer.”

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?

43 here and I was a CTO in my own startups that provided me a nest egg. Done Digital Transformation Coaching for a big chunk of it. But my last employer hired me after 1 year contract of doing this as tech lead. Much to my amazement because I don't really consider myself a good engineer, I'm just good at solving problems and was able to deliver stuff. Most of the times it isn't always as pretty as it should but people are happy. Except when I get those nasty job interview algo questions which I mostly bomb.

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 :)

> 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.

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.

Sounds ideal. Do you code much still as part of that?

Not as much as Id like. But that generally comes down to prioritization and the broad autonomy & area of responsibility in these roles. The self reported survey data of time spent is that principals are doing direct delivery 12% of the time median and 20% average.

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.

Thanks. I really appreciate the reply. It matches with what I thought might be the case. I've taken on a more senior role lately as my career progresses and I'm finding I'm spending only half my time doing direct delivery and the other half doing project management type work and coordinating changes across teams etc. I love the autonomy that comes along with it but I'm so used to the idea of getting paid to cut code that when I don't cut as much as I used to I feel like I'm not keeping up. Reality is I'm busy with other stuff and I'm learning to just accept that more and start to lean into it.

You’re welcome. My advice would be to keep the development up, but focus your efforts where they make the most difference. When it comes to grinding LOC, and even defining entire components, that’s what you have a team for. Trust them to do the needful, or intentionally lead by example until they can. Spend your dev time discovering/removing the complexity or laying the groundwork for the bulk of development to follow.

Yes, I did exactly this. Stayed a dev, moved to the west coast, got a big pay bump, job stability, and benefits. There are plenty of 40+ devs here. So much of the work at big companies is learning their huge custom domain, don't worry about any particular tech.

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?)

Did you "declare" a target level when you applied?

You don't, not directly. At least at msft. But you can figure out what level you think you should be based on your experience, and then work backwards to determine what base salary to ask for, and the levels are fairly tightly coupled to that.

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.

>it's much slower and less interesting. But, still worth it....I guess. (second-guessing myself now?)

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!

I joined Google at the age of 50. Just send a resume. They are not trying to surprise you and want you to do your best. Consequently, not only do they tell you what to expect from the interview process, the recruiter will send you a PDF that talks through what to expect along with a reading list you can use to prepare. (For example: cracking the coding interview and CLRS are on it.)

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.

You advice is sound but incomplete.

> 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.

> You must make sure your result is the smallest in lexicographical order among all possible results.

Can someone explain this? I can't even parse that sentence.

in other words, the shortest string in alphabetical order

Smallest as in order not length.

In the second example with input cbacdcbc a possible solution would be cbad but acdb is "smaller" (ordered before).

It seems odd to want to preserve the ordering among the surviving letters while still involving alphabetical order somehow. Those motives are usually mutually exclusive in the real world.

As an engineer, before starting to code, I'd first ask if the customer would prefer "abcd" or "cbad" for the second example, as either would be far cheaper in terms of development and maintenance costs to do. It's somewhat common to discover that they're just taking the "acdb" you're giving them because that's exactly what they asked for, and then they're alphabetizing it to "abcd" afterward on their end, anyway. But sometimes, there is a legit reason for the weirdness, and the customer is willing to pay for the extra effort.

Whenever someone seems intent on aiming at foot and pulling trigger, always ask "Are you sure?" and "Why do you want that?" at least once before helping them do what they want.

The "read hypothetical; code answer" type of test doesn't quite capture that like the interactive interview discussion does.

Basically alphabetical order, but if you don't say lexicographical, it doesn't sound as smart. (I am assuming it's a more comprehensive term, having to do with other characters, other than simple letters, so that if integers were used, it would appear as 1234, where saying "in alphabetical order"doesn't make sense. But yeah, I did a double take.

If you remove the duplicates from the string:

CACB

You can get either CAB or ACB. If you were to order all of the possible results of removing duplicates (in this case only two, but obviously many more for more complex strings) and order them alphabetically, then take the lowest one, that would be the right answer.

For what it's worth, I've interviewed 200+ engineers at Google and I think the problem you linked is not a good interview problem. I'm sorry you were asked it!

A good problem gives people with algorithms ability a space to demonstrate that, but it should also give space for demonstrating strengths in design, coding, communication, etc. This one is almost all algorithms, of the "have you seen things like this before" variety, plus a small amount of code.

Does Google interview training emphasize that? Even in companies that claim not to give leetcode questions, they do pop up; everyone isn't really on the same page and there seems to be a lot of luck involved.

I went through interview training 5+ years ago, but that was covered then and I believe it's still covered now. Because interviews are mostly conducted by engineers who do it as an occasional thing there are many inexperienced interviewers.

(Speaking only for myself)

Yes.

The other important bit is that you often don't need to just find the optimal solution to get good ratings. For the question I used to use, I've had perhaps one person get the optimal solution without any hints. None have solved the extensions without hints. I've given more than one Strong Hire rating.

> Let me give you and example of what I got at Google: [...] 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.

I have never tried to solve such problems before, but wouldn't it be enough to convert the string into a set of chars, then into an array of chars, sort it, and return it as a string?

> wouldn't it be enough to convert the string into a set of chars, then into an array of chars, sort it, and return as a string?

No. Please re-read the problem statement. It's way more complicated than that. If you figure out how to do it, try to figure out how to do it in O(N).

The proposed solution isn’t optimal but it works. Not sure what you think is wrong with it?

An optimal solution would be something like

- create an array of 26 or 52 bytes depending on whether this is case sensitive

- iterate over the string and set the byte corresponding to each letter’s position in the alphabet to 1

- iterate over the byte array and for each 1 you encounter print out the corresponding letter

Won't that give you the letters in alphabetical order, which may not be correct? See example 2 on the problem page.

> Won't that give you the letters in alphabetical order, which may not be correct?

But that's what "lexicographical" means?

> In mathematics, the lexicographical order is a generalization of the way words are alphabetically ordered based on the alphabetical order of their component letters.

> This generalization consists primarily in defining a total order on the sequences (often called strings in computer science) of elements of a finite totally ordered set, often called an alphabet.

https://en.wikipedia.org/wiki/Lexicographical_order

I think the problem statement wants the lexicographically least string of those obtainable by deleting characters.

>The proposed solution isn’t optimal but it works. Not sure what you think is wrong with it?

Consider the input “ba”

This solution will return “ab”, which is not a strong that can be generated by deleting characters from the input.

I've just finished the 2nd year of my CS degree. In about 3 minutes I came up with:

1) create an empty string, call it "S2" 2) loop over each char in original string 3) if the char isn't in S2, add it to the end of S2. If the char is already present in S2 then lexicographically compare the prior S2 verse S2 with this char shifted to the end. Keep the lower ordered one.

This took about 3-4 minutes of thinking and is O(n). It might not be optimal, it might not even be a correct solution as I've spent only a few minutes on it. However, I feel it's close and it wouldn't take much to flesh out.

EDIT: This solution is incorrect.

Here's what I came up with after experimenting with handling the leetcode example ("given cbacdcbc, produce acdb") manually:

Build a suffix tree ( https://en.wikipedia.org/wiki/Suffix_tree ) of the input with two modifications:

1. When adding a letter to the suffix tree, skip any paths that already contain that letter. (Thus, each path will contain a given letter no more than once.)

2. Include accounting information in each node specifying the length of the longest suffix including that node.

From wikipedia, construction of an ordinary suffix tree takes time and space linear in the length of the input string. At this level of analysis, I'm just hoping that modification #2 doesn't affect that. #1 certainly won't, in that it involves spending less time and less space than otherwise (by bailing out early under some circumstances).

Once the tree is constructed, just walk it, selecting at every point the child that is lexicographically earliest among all children with the maximum suffix length.

Observation: constructing this tree by hand really feels exponential; I suspect that the linear time and space requirements lean on an assumption that the size of the alphabet is finite.

Observation #2: Based on the comment timestamps, this took about 40 minutes of thinking. I think it's a good solution, but it probably wouldn't look great in an interview. (Also, handwaving "construct a suffix tree" is fast, but actually producing the code to do it takes extra time.) :/

Observation #3: assuming your solution is correct, it is essentially a reduction by dynamic programming of this one, only doing the calculations that are necessary to produce the lexicographically earliest string where I produce them all.

After playing with suffix trees a little more, I need to make a correction:

This problem asks for subsequences rather than substrings. As a result, when adding a node to the "suffix tree", it will need to be added as the child of more nodes than it would if we were building an actual suffix tree.

This seems like the type of change that might make construction of the tree harder than O(n). In particular, it will violate the constraint that a suffix tree for a string of length n has only n leaves.

input: "bcabc"

  1. "b"
  2. "bc"
  3. "bca"
  4. "bca"
  5. "bca"

What am I missing?

Nothing. I hadn't fleshed out my idea yet and that's the error I thought could exist. My solution is wrong.

Take all the possible answers with duplicates removed, and return the first one in alphabetical order.

input: "bcabc"

output: "abc"

that is a single line of code in javascript, assuming you just want the value in #5 const foo = [...new Set('bcabc'.split(''))].join('')

That solution as written is O(n^3)

This is not an easy problem.

You only check each character in the string once. A hashmap can check if the char is used already.

For each char in the original string there is: * 1 check in hashmap (let's assume it was found). This is O(1) * build a new string where we remove that char from the string we are building (string2) and add it to the end. This step may look O(n) initially since we need to find that char in string2 but string2 is capped at 26 characters so it's O(1) * One comparison between the string we are building and the altered version.

How does that make it O(n^3)? I can't see which step inside the initial loop is O(n) or greater.

EDIT: The solution is actually incorrect so this is now semantics.

> EDIT: The solution is actually incorrect so this is now semantics.

Interesting use of "semantics".

The question of "how fast does this algorithm run?" is totally independent from the question of "what does this algorithm do?"; the second one is semantic but you're discussing the first here.

The algorithm I described was O(n), you said it was O(3). I'm assuming this happened because my algorithm was actually an incorrect solution but you subconsciously added in steps to make it a correct algorithm which changed its complexity. Hence it's semantics because we seem to be discussing two different algorithms.

Can I ask about the suffix tree solution? A one-hour problem is still pretty easy in the grand scheme of things.

I think I'd rather solve real problems than some basic algo I'd never bother to write myself. If Google just wants basic algos and will likely filter me out during interview because of that, I'd sooner not bother. This is probably why big companies complain of talent shortages. Also why they forget real people and start going on very strange tangents. Stupid filters. Good.

I'll stick with creating actual solutions for real people with real problems. So much easier. shrug

As I'm in a similar boat to the OP, this is exactly why I'm hesitant to even interview with any of these companies, even as a test to see where I stand, simply because I fear I'd be blacklisted on some list these companies might share, should I bomb one without a lot of time spent reviewing.

I sometimes follow a Reddit sub geared for mostly recent CS grads. Every week or two will be a post from someone who got a FAANG job, detailing what he did in order to pass the interview. And some of these are pretty absurd - graduating last semester and since then spending 6 months going through leetcode 6 hours a day, studying algorithms, paying for interview training classes, etc.

And as an older guy who has a decent CS degree but hasn't needed to use 90% of anything related to algorithms in 15 years, I'd have to study a lot, and along with the numerous days of vacation time used for these interviews in California, it doesn't seem worth the effort.

> I fear I'd be blacklisted on some list these companies might share, should I bomb one without a lot of time spent reviewing.

AFAIK they only blacklist you for 6 months and then you can try again. Even that may be relaxed if you're trying for a different department or, especially, geographical location.

> numerous days of vacation time used for these interviews in California, it doesn't seem worth the effort.

In India at least, the big companies handle this better than smaller ones - they have one or two telephonic interviews to begin with and then finish off all the face-to-face interviews in a single day.

Well this was a fun distraction! Took my no-CS-degree self a few tries to get it, but I got it[1]. I doubt I could have done it very well in an interview setting, though. A bit trickier than it looks at first for sure. Good practice because I have a coding interview tomorrow.[2]

12ms w/ 2.1MB memory usage - apparently 25 percentile for speed and lower memory usage than 100% of submissions in ~50 lines of Go.

[1] https://leetcode.com/submissions/detail/292246392/ (Not sure if you can deep link in to leetcode like this?)

[2] I am looking for a job! Hit me up! https://news.ycombinator.com/item?id=21937576

> [1] https://leetcode.com/submissions/detail/292246392/ (Not sure if you can deep link in to leetcode like this?)

It seems you cannot, 404 error.

Can you elaborate on how technical writing can help you excel at a google? I write docs at my company all the time (that garner a lot of views) but I feel like most of the time it goes unappreciated except for those few individuals that actually need them to finish a random one-off task they were assigned.

(At Facebook, not Google) when the technical writing is used to influence a technical outcome. Particularly a strategic one. a well written memo can change the way business is done and there’s not much ambiguity around where the idea came from.

That said, being an eager doc writer in an effort to claim credit or inflate the perception of your own work is a great way to lose friends and alienate people.

Why do they get offended that you are consolidating knowledge?

Not the OP, but there can be a perception (whether justified or not) that people who "just write docs" aren't coding (taken as "contributing in a meaningful way") but instead optimizing for their own career/promotion. (This is not a viewpoint I personally hold)

Just as one data point - I went through the onsite recently and I personally found that PDF to be unhelpful. While it does list everything you need to know, it also lists way too many things that you probably don't need to know. It's basically an exhaustive list of basically every resource and topic that could possibly show up in the algorithmic interview. In my view you just need to cover Cracking the Coding Interview and then do 50-100 Leetcode questions. If you have a strong grasp of intro algorithms that would work too, except for engineers like me who didn't major in CS and hence never took an algos course.

--- 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.

Once you get into a FAANG company, do you actually use these algorithms? OOP/FP design, "clean code", the System design I would see as important, but in an actual dev job how much does the hard-core algorithm stuff come up?

Big O is always extremely relevant. - A lot of the typical algorithms in djikstra, merge sort etc. are not important to know by heart, but they represent important concepts to know to solve complex problems. Divide and Conquer and Greedy or topics that come up implicitly at least once a week, usually more often.

> it also lists way too many things that you probably don't need to know

The list looks reasonable to me.

What things, in your opinion, should be considered optional/lowest priority on the list?

I've only interviewed twice at Google for engineering so take this with a grain of salt.

Here are some things I would depriotize: ● 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). > I don't know anyone who has had to write a sort in an interview. Obviously you should know big O notation and also how they work, but practicing the implementation seems like a waste of time. In fact in my onsite, I used the .sort() method mentioned it was O(nlog(n)) and moved on to the rest of the problem. It was a minute part of the solution.

● 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. > Again, while you should know how to use Hash Tables, I really don't think they would ask you to implement one.

● Trees and Graphs: * 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. > I actually still don't know how to build a balanced tree. It's never come up on any Big N interview I've had. The rest of this section is really important though, tree problems are extremely common in interviews.

○ If you get a chance, study up on fancier algorithms, such as Dijkstra and A (for graphs). > I dont know Dijkstra and I don't think it comes up that often. I have no idea what A is.

● Other data structures: ○ You should study up on as many other data structures and algorithms as possible. > I think if you know trees, tries, arrays, linked lists, and hash tables you will do fine. I only had one interview which had a different data structure (rope data structure) and the only reason he asked me the question was because I had never used it before. It was an intro question and if I said I knew it he wouldn't have given it to me. So I think if they give you another data structure, they are gonna assume you don't know it and will give you an intro question.

● 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. > I don't know anything in this area (besides real basics on processes, threads, and locks). Never had a question here. I wouldn't study unless you are interviewing at team where this is relevant.

○ 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. > Again I don't know anything about OSes. I am not a CS major and never had a question in this area.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. > Also don't think this is that important. You should know how n choose k works (because that is needed for measuring complexity), but I definitely wouldn't spend my time on discrete math.

Thanks for replying. This is helpful stuff.

Did you pass either of those 2 Google interviews? And/or get offers from other similar companies?

> I only had one interview which had a different data structure (rope data structure) and the only reason he asked me the question was because I had never used it before. It was an intro question and if I said I knew it he wouldn't have given it to me. So I think if they give you another data structure, they are gonna assume you don't know it and will give you an intro question.

Can you explain that a little more?

Specifically: “they are gonna assume you don't know it and will give you an intro question.”

I failed the first time and passed the 2nd. I'm interviewing now so waiting to see if I get other offers.

To explain, one of the interviewers walked in and asked "have you heard of the rope data structure?"

I said "no" because I hadn't and he was like "great because otherwise I would give you another question". He then asked me to build 2 key functions for the data structure. I didn't need to study it beforehand, and if I did he would have gave me another question.

I think if they give you an uncommon data structure the expectation is that you have prior knowledge of it. This question was the favorite part of my interview loop (we chatted a bit about how google uses rope data structures)

Thanks for elaborating!

Was this part of the interview challenging? Seems to me like a surprise data structure coming up in an interview could be a bad thing (in terms of doing well).

Edit: What have your other interview experiences been like? Similar to Google, or would different/more preparation be required?

Also, what level are you at/interviewing for at these companies?

I started at my second 'FAANG' company when I was 48, two years ago, and it's been great. The previous 'FAANG' company was less great, but still fairly ok.

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.

Same age, I recently interviewed at two FAANG companies.

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.

>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...).

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.

I was applying for a software engineering position. No particular level was specified. After the interviews, the recruiter basically told me that they couldn't make me an offer for a L4 position, considering my experience (I think he mentioned 7 years of experience). Interestingly, I had the exact same explanation at two different companies.

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).

Thanks, I hear a lot of stories of people being down leveled but it sounds like some companies have strict bands related to YOE. L4 appears to be mid level and I guess 7 yrs if on the upper limits of that but you'd think they'd give you the option of being down leveled or not to get your foot in the door.

Farther up the page is a comment that rings true to me: companies who have a surplus of applicants are prone to rationally bias their hiring practice to avoid making poor hires even at the risk of rejecting strong candidates.

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.)

Well, I'd argue it still isn't rational given that the testing done during the interview is usually not telling much about the candidates engineering prowess.

I probably agree with you, but I think that's a different question. Whatever metric you're using to decide which candidates to offer employment, there's a rational reason to hold higher standards if you believe you have an effectively infinite surplus of maybe-excellent candidates if you pass on the current marginal candidate.

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".

> "it sounds like some companies have strict bands related to YOE"

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.

L4 is an intermediary level between new-to-industry junior (new grads generally start at L3) and mid-level (L5). In many companies, it's expected that people will reach L5 within some time period.

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.

Is there a guide for what type of projects FAANG expect for L5+? There was just a thread here about a guy slacking for multiple years, so are their L5s even working on complex projects themselves?

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.

Basically, an L5 (or equivalent level at other companies) is supposed to be largely independently competent (but not necessarily excel) in most engineering areas. They understand the context enough to determine which projects are important (including those they might make), they can identify stakeholders and communicate status and needs well enough, they can project manage enough (or make a project manager successful), they can work through others to a reasonable degree, and so forth. They'll know those areas they'll never be good at, and have some mitigations in place for those. They're self-motivated, think about their work holistically, and generally will navigate the delivery of the project without guidance - but when they need it, they'll make sure they get it.

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").

Thanks, those are reasonable expectations a candidate can demonstrate at any company. OP qualified further that they didn't even consider his projects, the bar is just raised some on the interview questions. That's reasonable.

> Failing to have grown skills and project scope to L5 level after extensive time in the industry

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.

I'm definitely not going to defend the industry's interview processes' effectiveness at consistently and/or accurately extracting useful information (or even just the information that it is intended to). When faced with the output of the process indicating this "flat" trajectory (however inaccurate that may be), that's just how some people interpret it.

Is there a generic reference for what these levels denote? I work in software but not at a FAANG, and haven't seen them used before.

Edit: I've now found levels.fyi - these are Google's internal progression levels.

> After the interviews, the recruiter basically told me that they couldn't make me an offer for a L4 position, considering my experience (I think he mentioned 7 years of experience).

Unless I'm missing some details, this actually sounds like age discrimination.

> 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?

ADEA does not cover people younger than 40

Google happily extended me a lowball L4 offer, despite my 16 years of experience. I think they seriously thought I would take it based on my less-than-prestigious work history.

> I wonder if years of experience or even achievements can be used against a candidate by raising the bar so to speak.

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.

aka, blatant age discrimination

its not random, you can learn how to hack it by reading these on leetcode

https://leetcode.com/discuss/interview-experience/360829/ama...

I would not recommend trying to interview as a manager for any large tech company without having first been a manager in another role. I would also not recommend doing this for small startups, but some may be willing to hire you into such a role without you being able to point to concrete experience in the role (the filters aren't as strong).

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.

> I would not recommend trying to interview as a manager...without having first been a manager in another role.

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.

What's the bar for being hired as a FAANG engineering manager? Prev FAANG management experience? Prev FAANG IC role? Cursory LinkedIn searches show many FAANG engineering managers were promoted from within or came from a similar position at a similar company. 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.

Thanks.

Being hired in as an engineering manager requires having been an engineering manager previously (at any company), generally for a reasonable period (let's say, minimum two years of full-time management experience minimum with at least 3 direct reports), with a career YOE of around at least five years. You're generally coming in at the same pay band as a senior IC (you might be able to see this sort of information in levels.fyi), so you'll be in the same ballpark of experience/career trajectory.

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.

Thanks for your thorough point of view.

What are the interview questions aligned towards? More soft skills, or are there still a bunch of algo questions, etc?

I don't know if this is as standard across the FAANG (and similarly styled companies) as an IC interview is - some companies expect managers to have been able to be successful as mid-level ICs, and some might not. Recruiters will generally happily describe company's process to you if you're applying, or will tell you if you ask if they reach out to you.

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).

I joined Google last year, hired directly as a manager. Germane to this thread, I'm in my early 40s.

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.

Can you share a bit more about what management questions you were asked, and perhaps a hint as to how one prepares for them? There seems to be plenty about technical questions, but not so much about management and leadership.

Also is the technical bar lower? And do they care at all about having done business school?

They are truly standard behavioral questions that you can't really prepare for, other than thinking about what you did in various scenarios.

"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.

No, someone shouldn't be discouraged in applying. But they should know that their chances are low.

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.

I have very similar experience. I'm 42, spent most of my career in startups / small companies in CTO-level positions, but last year took an engineering position in big tech (at one of the companies you mention).

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.

As someone in a CTO position now but being a serious IC ~5 years ago, I'm curious. How was the transition back for you? I love my job, but I also miss it.

So far (been about 9 months), I like being an IC a lot. I still get to be a leader and mentor, but have a lot less paperwork to fill out come review time! I always enjoyed the coding part of the startup CTO job more than the manager part anyhow. I feel that if I ever want to get back in to management, either at my current employer or somewhere else, I'll be able to make that transition pretty easily.

But if I go full-time manager, I don't know how easy it would be to flip back to dev / IC.

YMMV, but in my non-FAANG experience in the mid-/south- eastern US, tech managers seem to make at least 1.25X for X=senior dev salary. Maybe keep that in mind?

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.

> my non-FAANG experience

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).

As a senior manager of a development team at a Fortune 10 company that consists of many members who are in their 40's or older one of the things I'm looking at during the interview process is their ability to logic and reason. That ability alone seems to be so much stronger just due to living the ups and downs. Displaying this, focusing on this, is by far one of those things that makes you stand out.

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.

Just speaking from my experience. I rejoined Microsoft at 47. Loved it. There are a lot more grey hairs there than during the early days, and nobody cares (in a good way). You’re just part of the team. Go for it. Satya has done amazing things with that company, and in many teams it’s like working for a startup, but with the safety/security of a bigger co.

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.

I don't know where you live, but I'm guessing you're in the US. I'm 43 as well, been mostly the startup world for 20+ years - similar journey (worked, founded, etc). After my last startup got sold (not at best terms), I also took the time to relax a bit (and ended up rebooting another business and starting another instead).

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).

This is a great perspective and resonates a lot for me.

Curious though, to hear your thoughts on the incoming off-payroll legislation and how you feel it will effect the UK contracting market.

We've just been talking about this yesterday and today in the client's office, where most of us are contractors. It's an agency, most tech staff is on contract, the client is a government body where almost everyone there are contractors because gov pay is low and nobody will take the work on their PAYE rates. Spoke to my accountant who told me this whole IR-35 malarkey is under review at the moment and might or might not happen come April. He made a good point regarding IR-35 "insurances" saying that they are only offered because the chance of being hit by HMRC for that are slim to none which is why they are passing the buck to the clients. The problem is not HMRC vs the Contractor but now HMRC scaring the clients from hiring contractors.

Another friend told me his current client wants them all inside IR-35 which means a mass contractor exodus. He also told me banks are cutting the contractors as well. The problem for banks is that a LOT of their tech staff are contractors at high rates.

To be perfectly honest, I'm concerned to a degree. Both for contractors like me, and to clients who rely on contractors - come April, if this is not retracted, there will be a mass shortage of hands. Being inside IR-35 is like being PAYE without benefits and PAYE pay is significantly lower than contract one. This is quite a problematic situation.

Not an issue. I'm older than you by a few years and I'm looking for a new job. I have 5 onsites lined up with more to come. Age hasn't been an issue except for expectations at places like Google that want to interview and hire me at L6+ level which I know I'm not good enough for, hence why I was never hired. Otherwise I'm not concerned... yet.

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.

I am still in my 20's and recently switched team. Switching team made me think a lot about what I want to do in my life, and I still haven't been able to figure it out. I was feeling anxious and worried as I felt I am old enough that I should know what I want to do.

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.

I joined a FAANG company when I was about 40 years old around just a couple of years ago coming from a sequence of startups and smaller companies. I think the biggest adjustment to make is the performance review systems. At these big companies performance is not about doing right things, but about fitting in with insular expectations. The senior folks who you would hope could mentor you may have no idea that you don't "get it" or what kind of feedback it requires to make the transition. In contrast, a lot of feedback you get at smaller companies is to just focus on doing right things for the business and not worry about any defined expectations.

I have seen some people make the transition smoothly... others not so much.

I cold applied for an L7 position at "A" recently. Going in, I had fear that I was under qualified. My background is CompSci, Management consulting and leading teams at global 5 companies, startup founder, and other lead positions. I left the L7 interview wholly underwhelmed as I felt I was interviewed by engineers with experience an inch wide, one mile deep. Whereas I like to be a mile wide, 0.8 miles deep. My thoughts "maybe L8" is better didn't set well though...

edit: I'm in Denver, and here senior leader positions are not too common.

Very interesting metaphor of the engineering talent you sized up during your interview. Thanks for sharing that.

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!

:) I only create things, not document my stories.

Time to start writing :)

So you should separate tech companies, from companies that use tech.

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.

I was 47 when I joined Microsoft and am currently a principal engineer working as an individual contributor doing engineering work. Before that I was running my own startup for several years. There are jobs available in everything imaginable including product management, engineering, management, and blends of those three.

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.

Ageism is out in SV, because the biggest perpetrators grew up. Plus experience is worth a lot of money. If you're young or old, don't listen to those who say you can't do something. It's just one more form of resistance that successful people have to plow through.

I'm going to disagree. Yes, the biggest perpetrators aged. But in my experience it became more "50 is the new 40" than it went away.

I think it's even more than that. I've seen a few companies where "people over 40" are an underrepresented group worthy of specific recruiting.

What do you enjoy ?

> 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.

43? you young-uns crack me up.

> I can still keep up coding

This sounds like you are not confident of your skills. At 43, with 20-ish YOE, if you want to become a SWE IC at FAANG you better be good, and know it.

> but should I do that, or try for management?

no offense, but you sound like an 18 yo.

In all this time at startups, how is it you haven't learned how to make decisions? Sorry if I am being harsh, consider it tough love. :)

You might just be coming off in writing as being indecisive and lack confidence, whereas in real life you are solid. Or you might have the humility that only true seniority brings. I can't tell from here.

Either way, I don't think this is a question with easy answers that you can get from a forum. You need to do some soul searching. I would first settle the question of whether or not you want to go into management, not whether or not you think FAANG will have you as an IC. There are plenty of books on becoming a manager. Almost all of them suck, but that doesn't matter. You'll get some initial perspective from reading 1 or 2 of them.

Assuming you do want to switch tracks to management, I don't know at all how FAANG is at hiring no-experience managers at age 43. Personally, I like to be prepared so my personal plan in that case would be to get a manager job at a startup -- it should be super easy for you. Do that for 2 years max. Quit no matter what after that. (You need to make that your plan and stick to it.) If you like it, apply to FAANG! Note though that being a manager at FAANG is completely different than being one at a startup. But what you're going for is the resume builder as well as the experience of having direct reports. Ideally you'd get a job where you have firing authority. Not that you want to exercise that, but it changes things.

Now if you search within and read a couple books and decide IC is what you love, take a month to bone up on core algorithms and then go for it.

I'm not quite as old, but I struggle with this question too. Programming and building shit is my passion, and I'd probably be a terrible manager, but I've been conditioned to believe management is the wise path for aging software engineers.

Same and same except I have more management than programming time but I enjoy mentoring so that side is fun, if I want to scratch my own itch I have side projects for that when I want.

It's a trade-off though, by choice I'd be programming most of the time.

You can build a career as senior IC if you a) refuse to blindly obey, b) make sure your work always benefits people in the organization, c) you keeping learning new things and d) sharing new and old things with a lot of people.

I have both worked with and interviewed people in their 40s when I worked at a FAANG. Despite what's advertised by HR, culture tends to be org/team-dependent at bigger tech companies. I believe that you should be more concerned about culture fit which is something you can assess during the interview. If you decide to interview for an individual contributor position, I recommend that you brush up on algorithms. You can either target a company on LeetCode or go through a generic list of problems (here is the one I use https://theinterviewlist.com)

Your mileage may vary, but I think management role is hard to come by at bigger companies, unless you have a connection with existing management who already work there. So I would hit up your existing connections.

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.

I hate these questions because it honestly puts me off when I think about my future. It makes me scared of being old. 43 isn't even that old (isn't retiring age 65...?) and you seem to be confused what your profession is. I don't want to be in that position.

If you're 43, you should know what you want to do. If you want to code, go for a senior/principal programming lead position. If you want to manage, go for a managerial position. You're asking a question a 20 yr old should be asking which makes me extremely worried what the future has in store for me. I hope that when I turn 40 in 2029, I could still do what I love (which happens to be in programming), and not have to fret if I need to change professions or not...this is the way.

*Edit, I hope I don't sound like a jerk, but this is really what I feel. I hope when millennials like me start to hit 40, we can change the tech industry's age distribution and we no longer have to worry about problems like this.

As you get older you'll realize that "adults" don't know any better than you do. Consider that moving forward. Nobody has all the right answers, and even fewer people know what the right answer is for you.

I'm reminded of this quote by Baz Luhrmann:

> The most interesting people I know didn’t know at 22 what they wanted to do with their lives, some of the most interesting 40 year olds I know still don’t.

Incidentally, I'm in the same boat as the OP. I've done coding, I've done the management gig, not sure what life has for me in store in the next 5-10 years.

PG has one too (I think; a quick search can't find it) but there is a perspective change:

"At age 20 if you're not doing bad you fell good. At age 50 if you're not doing well you feel bad."

I find that to be true, causes you to question a lot of what you've done in your past, and what you're doing in your future with the limited time you have left.

My dad will be 75 in a little over a week. I told him I still don't know what I want to be when I grow up (I'm 43). He said he still didn't know.

A close family friend is a recently retired federal judge, about that age, maybe a little older. He and his family are some of the unpretentious, intelligent people that I've met. He said the exact same thing.

> I hope I don't sound like a jerk, but this is really what I feel

You are saying that OP's question makes you afraid. This has nothing to do with OP but everything to do with you. Go chart your own waters.

I just clocked in 30 and post like OP's make me rethink the position I've held up until now which is I have until I am 40 in tech. I love what I do and if there is a way for me to do for more than 10 years then Great!

> If you're 43, you should know what you want to do.

LOL no. I'm 43. And I change my plan more now as I get older. Probably as I am less scared to change and no longer live paycheck-to-paycheck. The kids act like a small anchor to prevent me from going backpacking for a year but otherwise feel free to change my mind all the time.

Granted I have some friends/ex-colleagues at my age who knew what they would be doing until they retire. But they knew that when they joined some medium-to-big corp at 25-30 and never left.

But I also have more and more people my age (35-45) who change radically what they do as perhaps it is a midlife crisis or just realised they can afford to change now or need to before it is too late. I am not sure it ever is too late.

True, 25-years-old-me thought 35+ me would be a settled dad in a big corp and go fishing each weekend. And it turned out 36-years-old-me old left big corp to oscillate between startups and contracting and hacking each weekend instead.

> If you're 43, you should know what you want to do.

In a word, no.

You can change what you want to do at any age. At 29, I chose to put academia behind me to "go industrial". At 37 I started my own company. At 51, I joined another company. And again at 53.

You might have a general idea of what you want to do at some age, or something very specific. A particular itch you wish to scratch (see my 37 year old self wanting to prove that I could do "it" better than some of my predecessors).

Today, my 54 year old self wants to continue to enjoy working with very smart people, on hard projects, making material impacts upon top line and bottom lines of larger companies. In a real sense, my employer, those who actually pay my wages, changed 6 days ago.

In all these transitions, I've altered what I did, what I wanted to focus upon.

You shouldn't be scared of being old. Age is, for the most part, only a number. It is not relevant, unless you wish it to be. Or deal with some idiotic companies that think it is important.

You retire when you want. A friend 10 years my junior retired 2 years ago. He's bored silly now, but still, you can choose what to do, when you want to do it, modulo physical/health issues. For me, I think I realized I couldn't keep going at the powerlifter rate in the gym after I hit 53. I had to leave weights for the younguns to lift :D

I joined AWS 6 months ago at 43 as a principal engineer, transitioning from a CTO role of a Series D company, and wrote about it.

https://code.dblock.org/2019/11/17/the-pros-and-cons-of-goin...

I would recommend it.

in your 40s your big picture management skill would be more valuable than technical skill.

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.

> in your 40s your big picture management skill would be more valuable than technical skill.

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 yes, but in tech management:

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.

You should brush up on protocol buffers. Oh and containers. Mostly protocol buffers.

If you don't care about dealing with the headaches of enterprise/corporate and know what you are getting into then sure. Not for me. I've tried multiple times after 15 years in various startups (and .edu). The kultur of a large company is a deal breaker. I'd suggest looking into consulting or , if you can do it, find a large company that needs 'SME' and 'Fixer' skills (if you have those). You can then approach work offsite or telework varying your vista on the basis of what project needs your skills. Defense contracting has a lot of this type of work.

Not in my 40s yet but I'm in a similar position. I'm going to take some time off and prep for FAANG interviews. The benefit of the algo focused interview is it seems like there would be less ageism there as less of the criteria is based on behavior or fit type questions. Maybe I'm off here but that's what it appears like. I recently attended a Google recruiting event where a lot of the Googlers there were over 40 and recently joined the company, a couple of people even looked to be over 50.

i'm at the same spot. I've found the team lead role in the consulting industry to be enjoyable. I mentor junior devs (whole career mentoring in addition to technical mentoring) and try to setup Sr. devs to do their best work. I still get to write code and scratch that itch too.

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.

I'm in a similar position. I think if you have experience they really try to interview you for senior positions where you are defining technical architectural standards and teaching others. That makes it tough if you just want to code, but maybe suits you.

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.

"I can still keep up coding, but should I do that, or try for management?"

HN can't answer this for you. Which do you prefer?

I think the unspoken question is whether it is more prudent for a person of this age to pursue an individual contributor role or a role in the management track. Take this for what it's worth, but anecdotally I've heard a lot of programmers find that once they hit this age, opportunities as an individual contributor are more limited. So if the goal is to get a stable job at a large tech company, then the question is which track to pursue, and I think the decision process should go like this:

Really love coding, really hate management: Apply for IC. Tolerate/enjoy management: Apply for management.

I am a great people manager, but it's subject to the monkey in the middle problem, which I find stressful.

Why not try sliding into project management or product management? It’s not “real” people management since you typically have no direct reports, but these careers allow you to remain technical and I’ve encountered way less ageism here.

Broadly, you will experience significant ageism trying to come in as a coder/technical type. Probably less of this as a manager.

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).

I don't think age really has much to do with it. Apart from having more experience, joining somewhere in your 40s is pretty much like joining somewhere in your 30s. If you want to code, code. If you want to manage, manage. But don't decide based on age.

42 at MS

All valid points but this is very personal, no one can answer this. This question alone requires you to meditate on your personal preferences. "I can still keep up coding, but should I do that, or try for management?"

It basically boils down to: what are you more comfortable with?

If it is management, go for it.

If it is coding, be open about your expectations and go with a company that values your experience while accepting that you're there 9 to 5.

Sure go for it. Pick one company and apply as a manager or lead and pick another and apply as an IC. Decide what you want to do. Tailor your resume for that role.

1. Can you do the job? 2. Are you reliable? 3. Will you, as a human being, negatively affect the team?

Those are the things I try to determine when I interview someone.

Depends what you want to do. Are you still passionate about coding? If not they I would suggest management.

I've interviewed and failed often enough (with google) to know it is never going to happen.

I'm a Sr Manager at a FAANG company (and I started here in my 40s). My direct reports include other SDMs, senior product managers, and staff/principal engineers.

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.

> 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.

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’ve tried this strategy a number of times and I wish it was that straightforward.

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.

I'm curious if you can answer the question I posed on this thread a few sibblings up. Thanks.

It looks like another user answered your question and covered it well, but I'll add my own color as well.

>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.

I should be clear. I’ve been in hybrid or management positions for many years now so it’s not a matter of trying out managing, it’s a matter of going in cold.

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.

Answered at https://news.ycombinator.com/item?id=21985518

what does it matter? global warming going to send us into an apocalypse in 2-3 years anyways.

That's a pretty broad question, isn't it? Besides your age and that you used to work at startups and dislike the stress, there isn't much to go on for guidance. Who knows if you're suited for management, would be better as a code monkey, or what skills you need to brush up on?

Not to be disrespectful, but your response sounds like those arrogant Stack Overflow responses that are simply not helpful. There is enough in his question for anyone to provide a proper answer.

> Not to be disrespectful

It's okay to be disrespectful. It's not okay to preface that disrespect with an overtly false disclaimer.

It's actually NOT okay to be disrespectful. Saying someone's response was "arrogant" is not disrespectful; calling them stupid for being arrogant - that would be disrespectful.

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.

It's precisely because I'm not oversensitive that I see disrespect as a normal and at times productive human response.

You can define "disrespect" however you wish. It matters little to the recipient who undoubtedly feels slighted at the "arrogant" characterization.

Jimmy,

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.

"I'm not putting you down [then puts me down]"

You did it again. Please, it's okay to put people down.

The only question (and it appears to be the majority of the responses here) that looks like you can answer well is if other people have done what he's considering doing. Maybe that's the discussion he's looking for; the comments to that affect are definitely good.

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.

I appreciate the response.

Reply on news.ycombinator.com