> Evans has held his present position with IBM since 1965. Previously, he had been a vice president of the Fed- eral Systems Division with the man- agement responsibility for developing large computing systems; the culmina- tion of this work was the IBM/System 360. He joined IBM in 1951 as a junior engineer and has held a variety of engineering and management posi- tions within the corporation
Dated 1969
https://bitsavers.org/magazines/Computer_Design/Computer_Des...
Next meme that needs to die: “back in my day, developers did it for the love and not the money”
You want a promotion because you want more money. Even though I have found the difference to not be that great on the enterprise dev side. But in BigTech and adjacent, we are talking about multiple six figures differences as you move up.
I work in consulting and our bill rate is based on our title/level of responsibility. It kills me that some non customer facing consultants want to have a “career track” that doesn’t involve leading projects and strategy and want to stay completely “hands on”.
We can hire people cheaply from outside the country that can do that. There is an IC career track that is equal to a director (manager of managers). But you won’t get there hands on keyboard.
On the other hand, a “senior” working at a bank or other large non tech company will probably be making less than $175K if you aren’t working on the west coast.
For instance Delta
This jibes with both my personal experience at BigTech, knowing the industry and various publicly available leveling guidelines. Sone are more granular
https://www.levels.fyi/blog/swe-level-framework.html
https://dropbox.github.io/dbx-career-framework/
The company I work for now has similar leveling guidelines, it’s also more granular.
But levels are defined by scope, impact, and dealing with ambiguity
I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait.
This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
Good to hear it
“Tell me about a project you’re most proud of?” Then I’m going to start asking questions about your decision making process, how you dealt with complexity and ambiguity, etc.
If all you did was pull well defined tickets off the Jira board, you’re not going to be able to answer that question well and you aren’t the type of person I’m going to delegate a very ambiguous assignment where you have to make good architectural and organizational decisions and have to deal with “the business” to disambiguate.
The next question would be “Looking at your resume, I see you have $x years of experience, if you could go back to one of your earlier projects, what choices would you have made differently knowing what you know now?”
If you haven’t led any major initiative, what are you going to say? “I would have pulled more tickets off the board?”
I interviewed someone from AWS at my last job, he thought he was a shoo in especially after he looked on LinkedIn and saw that I was from AWS. I guess he thought he was going to be reversing a binary tree.
No matter what I asked, he couldn’t describe anything he had done of note except be on a team who did stuff. I asked him had he led any features, presented any “six pagers” internally, blog posts on the AWS site, presentations - he had done nothing.
I passed over him for a guy at an unknown company who could talk about where he “took ownership”. That’s one of the Amazon BS Leadership Principals.
Hell I had a public footprint at AWS after only 3.5 years I had been there as a mid level L5 employee.