Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thriving on the Technical Leadership Path

keavy.com

Post reply on HN
Print view View original

101–110 of 139 posts

Re: Thriving on the Technical Leadership Path

#101

Post by saberience »

nilkn wrote: post #100
oarabbus_ wrote: post #99

Earlier quoted context omitted.

Would love to hear some examples of experts decreasing complexity and advanced engineers increasing complexity.

A hypothetical example would be one person spending a week or two setting up an extensive in-house Spark cluster to solve a problem that a second person in one day realizes can be solved on one machine using some clever shell scripting tricks. The former person knows a lot and may have been fully capable of the solution the second came up with, but they followed the wrong guiding principles in analyzing the problem a…

You could answer that example problem just by being someone who reads Hackernews a bunch, since the "replace spark cluster with random unix tools" article appears here regularly. IMO, that doesn't really define being a principal engineer, it's basic.

Re: Thriving on the Technical Leadership Path

#102

Post by 1MoreThing »

waltertamboer wrote: post #52

I can so much relate to the first paragraph. When you just start your career, you enter a junior role. It's than expected of you to grow to a medior role, a senior role and than somewhere along the line become a lead. Well, that's the biggest BS there is. Not everybody is a good lead. It's a completely different job compared to engineering. It takes people skill, organizational skill and it requires you to approach e…

Most places I've been at don't expect you to ever become a lead. Senior is often a terminal role if you don't want to keep climbing. But there is an expectation that you'll continue to grow to at least a senior level.

Re: Thriving on the Technical Leadership Path

#103

Post by throwaway87378 »

shantly wrote: post #61
virgilp wrote: post #13

Earlier quoted context omitted.

> Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun. It's not about JS frameworks, but if you don't keep up with technology _because it's fun_; and you also what to be promoted very high on the ladder (aren't happy with "just" an average job with average pay that lets you have a decent life outside work) by all means do yourself a favor and…

>> because you can't invert a binary tree in 20 secs in leetcode > It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20). My main problem is that I look like an idiot while wr…

It sounds like you are making a lot of rationalizations for not investing the time to practice live-coding and whiteboarding. Those are skills that can be learned, like any other.

Re: Thriving on the Technical Leadership Path

#104

Post by zippergz »

dominotw wrote: post #3

This is bad advice. If you are hitting 40's, please do yourself a favor and go into management. Yes coding is fun but, 1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun. 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun. 3. Spending your weekends learning the latest JS framework because you don't want to…

I agree with a lot of this, but I have not worked ANYWHERE that a high level IC engineer doesn't get paid more than a first level manager. As a manager myself, until I got quite senior, I always had more than one person on my team who made substantially more than I did.

Re: Thriving on the Technical Leadership Path

#105

Post by oarabbus_ »

nilkn wrote: post #100
oarabbus_ wrote: post #99

Earlier quoted context omitted.

Would love to hear some examples of experts decreasing complexity and advanced engineers increasing complexity.

A hypothetical example would be one person spending a week or two setting up an extensive in-house Spark cluster to solve a problem that a second person in one day realizes can be solved on one machine using some clever shell scripting tricks. The former person knows a lot and may have been fully capable of the solution the second came up with, but they followed the wrong guiding principles in analyzing the problem a…

Thanks for the example. Once I did some analytics consulting with a stealth startup with some very talented engineers. One of them was usingusing rsync to replicate their data from their eng server to the analytics server, and I (not a software engineer, but familiar with shell) was initially like "that's it? You're just using rsync instead of ?" But it was the simplest and most straightforward tool for the job.

Re: Thriving on the Technical Leadership Path

#106

Post by nilkn »

saberience wrote: post #101
nilkn wrote: post #100

Earlier quoted context omitted.

A hypothetical example would be one person spending a week or two setting up an extensive in-house Spark cluster to solve a problem that a second person in one day realizes can be solved on one machine using some clever shell scripting tricks. The former person knows a lot and may have been fully capable of the solution the second came up with, but they followed the wrong guiding principles in analyzing the problem a…

You could answer that example problem just by being someone who reads Hackernews a bunch, since the "replace spark cluster with random unix tools" article appears here regularly. IMO, that doesn't really define being a principal engineer, it's basic.

I don't even agree that this is a defining quality of a principal engineer. This is part of our standards for a senior developer, and it's something we coach people on from the get-go.

Re: Thriving on the Technical Leadership Path

#107

Post by shantly »

throwaway87378 wrote: post #103
shantly wrote: post #61

Earlier quoted context omitted.

>> because you can't invert a binary tree in 20 secs in leetcode > It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20). My main problem is that I look like an idiot while wr…

It sounds like you are making a lot of rationalizations for not investing the time to practice live-coding and whiteboarding. Those are skills that can be learned, like any other.

Sure, and I am training those. It's just tough to keep up with when you're happily employed, since you're spending 40+ hours a week working but not doing those things. The longer you're happily employed somewhere the harder it is to keep up with that stuff. People skills? Talking about your work? Plenty of that on the job unless you go out of your way to avoid it. You'll naturally accumulate knowledge, tricks, stories, successes to talk about. Bumps and bruises, too. Algo interview stuff and whiteboard coding? That's purely extra time training on evenings and weekends.

OTOH I'm already near the top of my earning potential as an IC in my area (and for most remote work that doesn't require some prior connection with FAANG & co or excellent skills at algo interviews) so I'm looking to move to roles that don't require that particular kind of prep and are higher-paid besides, tending to be more about concepts, people, and communication (architect, manager, that sort of thing). So I've done just fine working (and interviewing) the way I do, and hopefully the sorts of interviews I'm bad at won't be relevant to me a job or two from now, anyway.

Re: Thriving on the Technical Leadership Path

#108

Post by [deleted] »

baron_harkonnen wrote: post #19
nilkn wrote: post #4

In my experience, many companies legitimately don't really know what to do with very senior engineering staff. And how many distinguished engineers or principal engineers or technical fellows do you really need for your relatively straightforward technical challenges anyway? The IC track often fails to work in practice for the simple reason that technical work at an extremely high level is just not needed at many com…

My experience has been that the value of very senior technical staff is not that they solve "extremely high level" technical problems but they are very easily able to see how what appears to be a complex problem is isomorphic to a much simpler, easy to solve problem. The difference between expert and advanced/intermediate technical staff is that the advanced engineer has an understanding of complex solution and mista…

[deleted]

Re: Thriving on the Technical Leadership Path

#109

Post by airocker »

Spooky23 wrote: post #37
nilkn wrote: post #4

In my experience, many companies legitimately don't really know what to do with very senior engineering staff. And how many distinguished engineers or principal engineers or technical fellows do you really need for your relatively straightforward technical challenges anyway? The IC track often fails to work in practice for the simple reason that technical work at an extremely high level is just not needed at many com…

I'd say that 80% of the time, the IC track is bad for the ambitious, non-consulting engineer ultimately, unless your plan is to move around alot, which is a strategy that gets riskier as you get older and better compensated. Even for the consultant, the path to growth is... hiring people and leveraging their labors! End of the day, the size of your tribe or budget is a physical manifestation of your power in an organ…

Totally! I believe the debate can be rephrased in certain situations as : whether you want to always be the player or do you want to be a coach at some point. As coach, you remain relevant as you grow older and have a bigger impact on the team. And in tech, nobody stops you from playing as a coach.

Re: Thriving on the Technical Leadership Path

#110

Post by kevan »

nilkn wrote: post #80
pm90 wrote: post #72

Earlier quoted context omitted.

I think your view is seriously constrained by the assumption that you can't have both a manager and a senior IC on a team. You need both to be successful. Every team I've worked in that had success had both. In these cases, the manager relies on the team, and the IC to get a clear understanding of the root of problems. You don't need to be super technically proficient to understand constraints, but understanding why…

I'm not sure if you're actually disagreeing with me. Of course a team needs a technical lead who is likely a senior engineer. I think that much is obvious. However, that person is predominantly concerned with their own team's technology. As an engineering director, I have an entire organization of teams I'm personally accountable for, and I have to make sure the work that's being planned out meshes well with what all…

>>>> ...vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.

This might come down to cultural differences between companies. At Amazon leadership responsibility is formally baked into the upper SDE roles (Sr and above), literally in the role descriptions. There's definitely still value in being a technical manager, but that's not the only way to get formal leadership responsibility.

Post reply on HN