The difference between expert and advanced/intermediate technical staff is that the advanced engineer has an understanding of complex solution and mistakenly tries to apply them everywhere, so the net effect is to increase complexity. The expert typically sees simple solutions and method of resolving complexity and has a net effect of reducing overall system complexity.
Believing that the value add of experienced technical staff is to only solve really hard problem is likely caused by having too many advanced/intermediate people playing the role of experienced technical leads. All of the great technical team member I worked with always make call solutions simpler and easier to implement by knowing exactly what doesn't need to be done and what is essential.
First, if the title is real, then the term Principal carries serious weight, and hews as closely as possible to the best definitions of Principal Investigator (yah, academia has been busy making a mess of that)
More often than not, a good PI knows that all problems don't need the most powerful solution, some just need to go away. If a claimed principal is always applying the most complex solution everywhere, then they're bad at their job.
A good 1/3rd of my benefit is not going 'zomg - a hard problem' to my co-workers, its the exact opposite. And even when it is a hard problem, at least half the time then it's 'Don't worry - here's what Djikstra/whomever did to solve it'
I love advanced algorithms, and relish the chance to actually go try and make ones - that said, my main value is not that, its that some horrible new problem erupts, my job is to say, 'no, calm down. That's an old problem in a new suit'
That said, switch isomorphic to homomorphic - I'll give the seniors credit, they usually tag the isomorphic cases . :-)
The reasoning seemed to be autonomy. Until they hired people who were senior by age but not autonomous.
Engineering titles are a mess and it causes real problems when moving to another organisation.
The beauty of the model, to me, is in the separation of skills. Being an expert programmer doesn’t make you an expert in mentoring, or leadership, or architecture sometimes, and if the place you work has any flexibility with its career setup, there’s plenty of opportunity to branch out once you think you’ve maxed out your current tech tree.
... or you quit and get paid more elsewhere/go consulting/whatever ...
An alternate formulation of this would involve the second person above arriving at a new job, observing that they're using Spark on an expensive cluster to regularly perform a computation, and noticing that actually they could do the whole calculation on a single node using simpler tools.
Double digit-strong data science team: speechless
Team engineers: we need a high-speed design with advanced adders and someone who can do the difficult static timing analysis.
Expert: No, you need someone who actually understands VLSI design who can interleave time and space in an algorithm. At that point, you can basically use a single step up from stupid-simple ripple carry adders. And if you use non-overlapped clock generators you don't even have to do static timing analysis. The biggest wins are in architecture, not implementation.
Yeah, 33MHz design in 125nm means VLSI like it's 1999.
End of the day, the size of your tribe or budget is a physical manifestation of your power in an organization. Power is how you get stuff done -- all of the right answers don't matter if you cannot realize the outcome. IMO, it's critical to grow as an engineer to be able to get others aligned to whatever task is at hand.
My career is very much in the applied space -- my perspective is someone delivering solutions, not inventing tech. It may be different for different disciplines/scopes.
The interesting thing is what happens in mid size to smaller companies, where organization structures are not as well defined. You still need people here, however, if you know the stack very well or are a proficient IC, you can make contributions that can have a significant impact on the org, and gain the trust and allegiance of many engineers, albeit informally.
I've seen this happen a lot. A senior engineer will either create or integrate a new tool or process which makes life easier for other teams. They are grateful to the person and are much more willing to hear the engineer out for future designs and projects.
All that to say... just having a title doesn't get you anywhere. You have to build trust by delivering value, however incrementally. Maybe this is really trivial stuff, IDK.
I mean, what you described is one way to deliver senior-level impact for a team.
However, this has a very important problem. Every time you join a team, you have to build up this rapport from scratch. If you switch jobs every few years, you'll find half your professional time consisting of busting your ass to build up rapport, only to have to start from zero at the next job.
When you're hired as a manager, you don't need to do (this kind of) rapport building. You just tell people what to do, and they will build it.
Not half, all of your time will be busting your ass building up rapport.
Lets look at the alternative: you start a greenfield project with no understanding of what the rest of the company's stack looks like. Engineers know some person was hired to do something, and they may be interested in what you're doing, but they're probably not invested in it (the people who hired you are probably more invested, but they're unlikely to be the ones who have a deep understanding of the tech stack). You're facing an incredibly uphill battle here, as there are certainly going to be things that you will need assistance with (custom libraries, weird deployment frameworks, shitty deployment scripts that only one person somewhere knows how to get working etc.).
You may be a super genius, super hardworking person and be able to pull it off. For the average case, I am convinced this is a backwards way to approach the problem.
It doesn’t prevent you from using personal power and influence, although most organizations are setup to purposefully make it difficult to function that way.
Usually your best managers do both. Think of the best people that you’ve worked for in any environment. Usually they are people from whom you’d seek advice and counsel.
That's a pretty simplistic idea of how a manager wields influence imo.
I mean, they do this sort of thing, in order to show that they are superstar, and should get 2x the headcount they currently have, but they don't actually need to spend a year and a half convincing people with results, in order to be allowed to direct their existing headcount as they see fit.
A senior IC, on the other hand, needs to personally prove themselves at every workplace, before they are allowed to act in the role of a senior. You're expected to deliver the results of a manager, without the corresponding power. You're expected to exercise soft power, and you're expected to acquire this soft power on your own.
It is an incredibly inefficient way of getting stuff done, if you ever switch jobs.
Took me a while to understand this is true. You can't have an org with the wrong ratio of "architects/leads" and coders. Or tech leads and engineers, whatever terms you prefer. An org with 2 teams doesn't need 5 people coordinating cross-team work. An org with 40 teams needs more than 40 engineers, and so on.
The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product. Managers who try to babysit developers and tell them how to do their jobs tend to just slow things down and lead to lower quality results.
> The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product.
I think you're underestimating the degree to which doing this requires a solid technical understanding when there are dozens of teams involved and interacting with each other. In order for an engineering manager to bring their team(s) a clear plan of what needs to be done with few blockers or obstacles in the way, often a lot of technical planning with other groups has to precede that. As always, management done right is the sort of management you don't notice -- but that doesn't mean a ton of work isn't happening behind the scenes to make things very organized and clear for individual developers. You could have ICs do that, but they wouldn't be writing much if any code, and they probably wouldn't want to anyway.
I agree with OP, the purpose of a manager isn't to manage the technical side of things but rather the people side. It's why they have direct rapports: to manage the people.
A better use of the IC's time is to unblock them so they can meet with stakeholders and develop a rich understanding of the work in order to do it most effectively.
In trying to "shield" the IC from developing an understanding of the landscape they'll be working on, the manager may accidentally be preventing the IC from getting the information they actually need to do their job well.
Yes, and I think the point I'm driving towards is that if this is the stuff you want to do, you're really not an IC at all -- you're an engineering manager with zero reports who doesn't have any authority, so you're making life 10x harder for yourself.
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 those constraints exist requires a deep technical understanding, which is provided by the IC and the team. Using this knowledge, the manager has a perspective of the system and how to improve the system, and the manager tries to reason with the organization, trying to share that perspective with them.
The manager also relies on the IC to do spikes or POC's (or relies on the IC to select a crack team which have a good chance of success).
Most often, the IC has no interest in being in non-technial meetings all day, but the manager does. The manager loves working with other managers + product and helping them understand the issue, while the IC doesn't. The IC wants to spend most of their time on resolving technical issues, thinking deeply about the future and upcoming projects.
All of this to say: they're not exclusive, and both are required for successful teams. BUT, the idea that a technical manager needs to be super technical is not something I agree with.
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 the other teams are also planning. I cannot constantly be pulling in a dozen senior developers into every meeting every day to help me figure things out. I also have my own technical objectives I want to achieve for the company that cut across multiple teams or the entire engineering organization. Most of these considerations are technical in nature, and while a senior IC on one team can help they frankly don't have time to be involved in the whole process -- that would prevent them from succeeding as a senior engineer in their current role.
Under discussion is not the role of a senior engineer, but rather the technical track beyond that point -- roles commonly termed staff, senior staff, distinguished, principal, fellow, or even senior fellow. My core claim is there's more in common between engineering management and these roles than many folks tend to believe and/or realize.
Often an engineering manager is just someone at this level of seniority who also has rock-solid people skills and has been empowered in the organization to actually get bigger things done that cut across teams, though they may not themselves write code anymore.
Certainly I agree with you that not every manager needs to be deeply technical, but I think that for someone who is deeply technical, engineering management can actually be a much more powerful and interesting choice vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.
The other big disconnect is in the size of companies in question. At the larger companies, you can have a clear separation of roles, so that some people are almost exclusively managing resources, and trying to match resourcing to business objectives, while other people are much more exclusively focusing on technical issues and how they can achieve business objectives by making the right technical decisions.
In these larger companies, the issue of people on "The Technical Track" not having the "muscle" of people in management is really not true, or at least, heavily over-simplified. (And this is another definitions question; at IBM and Google, Staff, Senior Staff, Principal, DE, Fellow, etc., were all considered as on the Technical track and were considered very senior engineers. Yes, they generally aren't coding much by the time they hit that level; although you might be surprised how much Fellows are still coding.)
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.
Once the technology works well enough, and the ongoing changes can be supported by mid-level engineers, and there is no big challenges ahead, it's time to move on.
No, this is not how you grow in power and importance for 15 years within the same company. If you want that, management is your path.
There's a lot of business value in certainty. The value of the senior IC is the certainty that your business critical project will get completed correctly and on time. Sort of like how you want a good electrician to work on your house even if the job isn't technically that "hard".
I guess if you have a lot of title inflation things might be different. I've definitely seen places where a senior developer is pretty much anyone 2-3 years out of school who does a decent job but still requires supervision and oversight.
The bullet point list of strategic work that she provides mostly overlaps with what engineering managers do. It's valid to point out that you don't need people reporting to you to do it. It's very cool that she's been at companies that made that possible. But I think it's a mistake to say, as I think many commenters here are saying, that that's the only valid approach.
Sorry if I'm being dim - what's an IC?
If you're a senior IC and you're not exhibiting leadership in some way you're probably not going to be around for very long.
Here it's being used to contrast with both TL-ship and management.
your company and your boss have to support you (eg by not micromanaging, so that you can actually effect soft leadership), but the way you put it, failure is a foregone conclusion.
Strike teams seem to the most effective thing for ICs to lead, and having that be an explicit part of eng culture and the work processes is a prerequisite for that.
I've talked with many of my now manager peers and they seem to not understand that simply walking into a room with "manager" or "director" in your title gives you almost immediate clout (or something similar). Whereas if you enter a room as a "senior IC" there's just not as much authority inherent in your presence.
It's unfortunate, it's not right, but it seems to be true.
In addition, a lot of of the main decisions are being made by management before engineers even get involved. Don’t know how to improve this but from what I have seen in other companies this seems fairly standard.
I guess you need to stay tune for her next blog post.
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 engineering from a much higher abstract level.
Personally I was really unhappy being a lead and I decided to step down. I was doing more harm than good and no-one benefits from that. Not the company, not the team, and definitely not me.
FWIW, if you still have to work 50 more years before you can enjoy a retirement, you better learn what makes you happy and do what makes you happy.
"It is a significant exodus in a short time, and many former employees describe a corporate culture at the fashion company that is unwelcoming, stressful, and occasionally hostile."
It's not a manual for how to be the world's best boss or build the best culture.
It's an approachable, informative view of what to expect at each rung of the management career ladder. I'd argue it's good because it doesn't take an opinionated stance on the particulars of how to accomplish the outlined roles.
- Tackling technical challenges that span multiple technical and organizational systems.
- Researching and identifying the problems that could be worked on, a year or two from now
- Ramping up strike teams to help build a thing.
- Looking at the big picture including cultural, product and technical challenges, to help inform choices that would be best for the org, perhaps with a 2-5 year view.
- Forming strategies, writing proposals and pitching them across the company, for new architecture, systems or approaches.
Except for developing prototypes, assuming the senior engineer is actually doing that, that entire list are just foundational management/leadership tasks.
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 be someone "who doesn't keep up", is not fun.
4. Being paid less than the lowest grade manager, is not fun .
5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
There is no such thing as "IC track" for almost every one of us, please shake yourself out of your delusion.
I do spend my weekends doing technical work (mostly reviewing and testing other people's ext4 patch submissions, and/or reviewing papers because I'm on various program committees), but that's because I love to do those things.
> 4. Being paid less than the lowest grade manager, is not fun .
At least at Google, and at IBM, it's not unknown for IC's to be paid more than their manager.
> 5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
It may be different for people doing other kinds of programming, but at least for Systems Engineering, there's an awful lot of value in knowing how the various abstraction layers fit together, and more importantly, understand the business imperatives which drives even the lowest level technical work. (Things like maximizing ROI on storage infrastructure by making sure you can efficiently use nearly all the IOPS which the HDD's in your data center can deliver, for example, is subtle work.)
Also, at senior levels, you need to know how to lead technical teams, and that's quite different from people management. And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.
This is the worst part of the whole gig frankly. It's an awful place to be, all the responsibility and expectations but none of the muscle.
So the authority gets delegated down to the technical leaders, and while it can happen that there will be conflicts that have to be escalated to the VP or SVP level, it's usually because a team simply doesn't have bandwidth to satisfy a request, or are being given conflicting signals as to the prioritization of different projects, and so we need to escalate to senior management to either get more head count, or agreement that a given prioritization will mean that the project will slip, etc.
The technical leaders make the technical decisions, and are responsible for the technical decisions. Management makes the resourcing decisions, and product managers make the product decisions. Usually, it's pretty obvious whose domain a particular decision is in, and as a senior technical leader, I actually know enough about the constraints that I can tee up the question, with the tradeoffs, and then say, "but that's a product-level decision: do we ship with now, or do we slip and so we can add this particular critical feature? Note to management: if you don't like the velocity of the development, we badly need at least 3 more head count by next quarter or we will be presenting you with more Hobson's choices like this."
And that's fine with me; I don't find working with recruiters and negotiating with the CFO for headcount, or sitting in an all day meeting trying to divide up the headcount granted to the department to the various teams. Not having to do that is not "lacking muscle", it's being freed from work that I don't like to do.
See? There are plenty of ways to be a technical leader without being on the management track. :-)
What's the way in? Hope you find yourself in a job where there are leadership positions open and the stars align and you're promoted into one?
And you're dead right, not every place is Google or whatever. Hell I don't think Google's Google, mostly, in terms of what they actually do, but they do pay developers very well regardless, so there's that. But outside a handful of huge pure-tech companies and Wall Street, you better be moving out of development by 40 or so (earlier if you can swing it, really—god I wish I'd started making moves this way years ago), or your career's (pay's) in for a brief flat trajectory followed by a sharp drop way before you'd have liked.
If I'm interviewing you for a job at $COMPANY, I'm going to be looking for signs that you can exhibit leadership, and that's going to be way more important than whatever title that you might have. If you have the title, but you can't demonstrate ways in which you were able to demonstrate technical leadership, the title isn't going to mean much.
In corporate jobs, this is rarely the way in. Most likely, you'll have to convince your current manager (and maybe theirs) that you're ready to be a manager and look for a manager opening elsewhere in the company. If you think you're ready and your current employer does not, you'll have to look outside.
Years of leadership seems like a purposefully vague credential. It's not about a title; if you don't think you've been a leader at work, you probably weren't (or maybe you were and your talent just wasn't managed properly ¯\_(ツ)_/¯ ).
Also, get ready for a lot of gatekeeping. “Oh, you don’t really want to be a manager! It’s so much more responsibility and work. You should be happy to be a foot soldier for the rest of your career! Management is not all it’s cracked up to be. As you can see I’m stressed all the time! Now excuse me, I have to go close on my second vacation home in Hawaii.”
[EDIT] my suspicion here is that yeah, it's basically "luck into it". I mean that's how everything else I've done career- and pay-progression-wise has worked (luck into someone tasking me with something they definitely wouldn't hire me to do, but after I've done it for a few months someone else would) so maybe this'll work out the same way.
Is it even possible to find a management position outside without management experience?
I've been programming for 20 years and it is a struggle for me to find something "new" that isn't a mild variation of something I've used before..
There's only so many variations of an application that can bring something really new to the table that gives you that excitement of learning something new like the first time you "get" TDD or DDD, or that first time you successfully implement an efficient CQRS model, with eventually consistent events, or run a GraphQL API that swaps the challenges of REST for a new set of problems and so on. Switching industries doesn't help much either, as they are either just more of the same but with different vernacular, or so niche that you'll need to have really been there since day dot of your career anyway.
There's only so many new libraries/frameworks that I can get excited about, and the rapid state of change in many ecosystems means that quota is pretty much full 100% of the time. Languages, too. That's before we even tackle the problem of getting _hired_ for languages I've not had any professional experience with, and with the added bonus of 0 personal time to implement side-projects, and a lot of companies never needing to stray from their current stack.. it's just not going to happen.
So now the only thing left that tickles my fancy are the "abstract" problems.
Instead of now focusing on implementing code to fix a problem, I'm asking and researching the questions like "How can the platform (and not just application) be more performant?" or "What is that the team can improve on?" and "how can I improve the learning culture?" etc. and using my experience to, at first, recognise these problems that are invisible to a lot of people, but also gauge which ones are actual problems or mild inconveniences.
Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.
Don't forget that there are more possible correct answers to strategy than there are people to do it. Should your company continue to update the current project, work on the big re-write to fix all the problems, or abandon current products for something complete new? All of these are valid answers for different situations, and some of the reasons to choose each are not technical and so you shouldn't influence them.
I have a dozen projects I'm thinking about at any given time. Some will never get more than thinking about. Some are in progress. Some I'm working to get into progress. Some are likely to be needed soon and are just waiting for the time of need so I can save the day with a plan (if the likely need turns to reality). Some are bad ideas that I need to prove are bad ideas so that we don't go down a bad route.
I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.
> "it's the people managers making strategic technical decisions"
...was true in your case.
In my experience (over 2 decades now, wow I can’t believe it) the people making the broad, strategic decisions and influencing outside of their orgs all happen to also have direct reports and usually those reports are people managers too. They have titles like “director” and “VP” and “CTO”. How many of those people have you seen who are individual contributors?
If this is the case, your company's technical leadership track has a broken pay structure. You shouldn't need to go into management to get paid better.
If you’re in your 40s or 50s and not in a role where you’re “influencing decisions outside your own team” you’ll soon be in for a shock next (or next next) job interview.
Once time I interviewed at a place with a few managers that were in their late 20s. Turns out they were the senior employees only having been there less than 2 years. Turnover was less than 6 months, I passed on the job and my schoolmate was there 5 months. The place had a bad reputation.
(But if you're bothered by having a manager younger than you, that's on you; I'm not sure what the inherent problem with it is. When I was a manager, I managed people older than me; now that I'm a senior IC, I have leadership younger than me. Both things are fine.)
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 move to management.
> 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).
> 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.
I've been managed by former students. Worked out quite fine for me. Why wouldn't it? Age does not equal competence.... I'd rather be managed by a competent young guy than an incompetent senior. (bad managers are no fun, that I agree; but bad managers are not necessarily young; and young managers are not necessarily bad)
> Being paid less than the lowest grade manager, is not fun.
Being paid less than what you're happy with is no fun. But it's not really required.
> do you really need 20 yrs of coding experience to write CRUD apps
So don't write CRUD apps if you're better than that.
> What exactly are you bringing to the table.
In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.
> There is no such thing as "IC track" for almost every one of us,
If that were true, it all becomes a huge pyramidal scheme (you constantly need more young developers so that you can manage them as existing workforce ages).
I'll give you that: for most people, it's probably easier to advance on the management track than it is on the IC track. And the IC track in many companies is a joke (if you're not at the headquarters, advancing is an order of magnitude harder; also you advance easier by playing the advancement game than by being competent in what you do - but that may be true for management too). So yeah, it's not for everybody. But OTOH, middle management sucks... big time. For some people, it may be a good deal to sacrifice some cache upside than to turn into something they don't want to be. It all boils down to what you want to optimize. If you're happy with a good income, even if it's not the best that you could possibly achieve, IC track might be an option (still, change companies every now and then. It's much easier to promote this way).
ok. I was being facetious with that (particularly famous) example.
you are able to breeze through hard leetcodes in your 40's in a tech interview setting?
Why would you be faster at 60's vs 20's , not sure i follow the line of reasoning.
> So don't write CRUD apps if you're better than that.
Can you give me some examples of better things that actually require 20yrs of experience ?
Am I as good as I was in my 20s? No. But the truth is that most people can't do the simple recursion... very few places will deny you employment because you can't invent original algorithms on the spot. They'd just fail tou for simple examples like the one you presented. The amount of people who can't do a tree traversal unless it's DFS is staggering. (and in all honesty, not all of them are useless programmers... sometimes people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)
> Can you give me some examples of better things that actually require 20yrs of experience ?
I saw this just now. Lots of things can use said 20yrs of experience... maybe even some CRUD apps (e.g. to know what to not over-design). Some things you probably can't do right without extensive experience (say, design a new programming langugage; or a new datastore). E.g. Rich Hickey famously designed Clojure because he wanted a better way to do those "CRUD apps".
Also, it's quite easy to find a hard problem that you won't solve without extensive experience, no matter how smart you are (say: collaboration, data management & versioning in large AI teams). Pretty much any open-ended problem, really... remove all constraints and most programmers will get stuck. How many people can start with "void main()" (or equivalent) and actually release it to production, if the project takes a non-trivial amount of time to complete?
Re that example, I was just using this famous tweet.
You don't get a job solving simple recursion problems. You have to solve hard leetcodes.
Also, 2years ago (I think) I participated in Amazon TechO(n) challenge... I was 1st after the weekend, but couldn't work on it during the week (no time/ kids) so by Friday my solution ended up 5th or 6th I think.
[ninja edit] No, I'm not faster, I'm a lot slower. In fact I probably lost most of my speed in the first few years when I stopped competing... but it's not a linear function, at some point, you don't lose any more speed; and just a quick refresher every now and then can boost your abilities back to fairly high levels. And most interview problems are not really competition problems, they're fairly basic.
And no, I don't write algorithms from scratch currently, the company I work for might actually be characterized as "boring" by many people("robotic process automation" - look it up). But I've lived to learn that when there's lots of money involved, there's also lots of interesting problems to solve - one just needs to find them.
You seem to have gotten faster. For most people this knowledge tends to atrophy as they age. Maybe you are lucky enough to work at job that requires you to write algorithms from scratch ( embedded engg?).
What is your theory as to why that homebrew guy wasn't able to solve simple recursion problem ?
> people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)
It's important to note that this doesn't mean algorithm tests are inherently broken. People who can't solve _basic_ algorithmic problems tend to be weak employees. Rejecting them screws your recall (a few would be amazing if hired) but tends to improve the precision a lot, so the trade-off is often worth it.
> In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.
I would add the ability to look farther ahead at potential problems.
I have seen so many young people blocked by some issues that should have been spotted way earlier.
> 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 writing code. I pointy-clicky navigate too much for many's taste—doubly so when someone's watching because I start second-guessing every keystroke and so avoid keyboard navigation—and tend not to remember much about languages I haven't written a ton of within the last 48hrs, and even then if it's some feature or function I haven't used in a couple weeks I'll either look it up or poke and prod my way to the correct syntax ("it's either this way or that way... OK, red squigglies, must be that way" or "I think null can just be used as falsy but undefined is gonna throw in this language? Yep, there it is, cool, I'll guard it then" or I'll not be 100% sure about the order of arguments for a "map" function even if I used it ten times yesterday and I'll look at the IDE's hint to get it right, stuff like that). I'm much better at the "what" and "why" than the "how", without support from tools and the freedom to faff about a bit, unselfconsciously.
All that's even worse on a whiteboard, of course. If someone bet me $100 I couldn't write a solution to fizzbuzz on a whiteboard in any language of my choice, that'd compile if input verbatim, without looking up some stuff in the couple minutes before doing it, I would not take that bet. There's a decent chance I'd manage, but I quite literally would not bet on it.
I mean I've been (technically) designing & shipping software for pay for a long time and everyone's always told me I'm pretty friggin' good at it. I've often been the go-to guy for weird crap and "hard" problems. But I look like a total dipshit who doesn't know anything and probably wrote my first "hello world" last week, if you watch me do it in interview conditions. I pretty much only have a career in software at all because not every place does those.
On your points,it sounds more like bad interviews if they're about syntax, not about the logic.
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.
>>1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.
This is true. This doesn't bother me though. I don't need to find "this" job, I just need to find a job. You ask me to invert a binary tree, don't worry. I'll find a job someplace else, and you can find someone else that has less experience and knowledge than me.
>>2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.
Don't honestly care. If you're a manager and making decisions on your lifestyle and feel that everyone else should live like you...see previous answer.
>>3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.
Honestly, I don't have to. The foundations are the foundations are the foundations. Do I know how to use the equivalent of Redux in Vue.js? Admittedly, no I don't. I can google that. I may spend sometime looking up new stuff on my own, because I find it fun, but this doesn't stress me out. I can figure it out. You don't hire me as a framework jockey. That's not what I do. You want me to go up against some younger person who spends his time learning React and can tell you the syntax off the top of his head. OK, fine. Call me when your database has scalability issues, or your web server is overloaded.
>>4. Being paid less than the lowest grade manager, is not fun.
Yes, we'd all like to make more money. Here's the thing. I make enough money to live the way I want to. To think that all senior developers can become managers is a joke. Management is an entirely different skill set, and news flash, it's hard. Like really hard. The best manager understands things like accounting and finance. You have to keep track of head counts, who gets what raises, why do they get them. If I give this person a raise and not as much to this other person, will someone leave? How does that affect my staff. Do you understand how to counsel people, because whether you like it or not, you're going to do that too. You are a people person, you get to hear all the things that go wrong, and sometimes you need to understand how to fix them and other times you need to just listen, and you have to know when to do both. Are you ready to put your job on the line when you find out that another manager, or someone above you is sexually/discriminating or harassing people? You get to do that too (blah blah, laws against that. They can do that. Get back to me in the unemployment line on that.). Have we talked about firing people? How many people have you fired before? Not a fun requirement. How many people have you laid off that are perfectly good at their job, because the company wants to hit their bottom line?
Managers may make more money than me ... when they're working. Just think how many managers vs engineers there are in the workforce. Let that sync in. You're competing against a lot of people that are or want to be managers for maybe what a 10th of the spots. Competition is a lot stronger, and that's assuming the open positions aren't been filled by people from within.
>>5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
What am I bringing to the table? That's easy, 20+ years of coding experience. I've seen enough to know you shouldn't do things a certain way, or a whole range of problems that people who just started out didn't even know existed. I know which log files to look in on a web server when there is a de-serialization issue. I know that a particular linker embeds a date stamp 60 bytes into the header of an assembly. I also know how to write and communicate technical problems to an audience in a simple way to allow them understand the const benefit analysis of a particular approach. You don't pay me to write code. You pay me to solve problems, especially ones you didn't even know you had. Some of them are coding problems, a lot of them are not.
Here is why - (for the sake of discussion, "principals" refers to principals and above)
- In an org, lets say as a director, I find I rely on my principal engineers to objectively tell me what the right thing to do is. They have less political motivation.
- Principal engineers almost unilaterally have a series of noteworthy accomplishments that create a catalyst for innovation for all engineers around. The depth they create inspires people to really understand tech.
- Discussions with them require managers to have more depth themselves. Rarely can managers win arguments without brushing up on tech.
- Regarding some comments about "CRUD apps" as universal easy things all engineers can solve I find perplexing. Problems in distributed systems are all trying to make CRUD possible and organizations are still figuring out how to do that at scale.
- Regarding arguments about ageism for principals, yes, I agree that ageism exists to a certain degree. However, I find most principal engineers are older as you go up the chain. Therefore, what you are really saying is ageism exists for engineers < principal level. Where you can have new hires know the same depth as them and pay less for. Can you imagine trying to hire folks that built S3, Python, Kafka, etc. be replaceable by younger folks?
'When I was on TV (Computer Chronicles) in early 1987 showing our product Trapeze the other presenter was Mike Slade who was product manager of Excel. At the time young me thought him some random marketing weenie (young people can be pretty stupid). Yet he started all these companies later including ESPN, worked for Apple in various leadership roles, was a good friend of Steve Jobs and started his own VC firm'
i think she makes a really good point here: one that's often overlooked by the "improve"-everything-all-the-time culture that a lot of contemporary tech inveighs.
it's easy to advocate solipsistically for an alternate solution that you came up with. it's harder to objectively weigh the merits of extant design decision and admit that your predecessor made an optimal (or more-optimal-than-you-can-muster) choice and defend it. iconoclasts may occasionally create great things independently (perhaps if they're a Linus Torvalds or a Margaret Hamilton), but the meat and potatoes of building functional and robust software is building well on solid foundations, specifically by respecting those foundations when they're sound.
Some of the above decisions have a technical part, but none are entirely technical questions.
you're telling me there's a difference between a principal and a senior principal? this seems like title bloat (non-financial, meaningless compensation)
i think there are just way too many senior engineers and not enough work for them. this title thing feeds into my hypothesis: if you're getting to the principal level and then encouraged towards "senior principal" level, that's an illusion of career progress.
i think more senior engineers expect to carry the sort of intellectual freedom they had as high output juniors forever as they become "organizationally woke elite hackers". that's just not a good way to portray yourself, though: eager juniors like that person once was will do the job at 75% cost, and not try to occasionally wade into politics as this free roamer has empowered herself to (ref. bullet about cross-organizational lubricant type)
i would be extremely wary of portraying myself as an "elite hacker with enough confidence to meddle across teams" because that is about as vanilla as it could be in 2019. instead i would slot in with an enterprising managerial type and basically become his code peon, pumping out his prototypes, giving him the credit where due, and understanding that he's generating the ideas but not the code, so he can't ghost you very easily and (maybe) he'll keep you safe in the event of layoffs.
this keeps you learning new tech and always building, but makes you really valuable to someone with organizational power, so safer than some generic engineer on a larger team.
And I find more and more that using this as a lens solves lots of these sort of conundrums
What do we do with senior / principal engineers? can be translated to "what shall we do with these really good readers and writers we have hired"? The answer is not invent some parallel path in the company to have them walk around looking for solutions - they become leaders of the organisation ... or they go out.
And as for the C-suite. No CEO ever announced that "well I used to read and write but I don't have time for that anymore. I do enable my skip levels to do more reading and writing on their 20% projects however. Sometimes I dream of taking a week off in order to write something - maybe an email, like the good old days"
If the management of the organisation is spending less than half its time coding, the company does not have enough automation and will get its arse kicked by 2030