If I need some basic plumbing work done, I'm far more likely to hire even a relatively inexperienced plumber than an MIT mechanical engineer with very little practical experience.
And if I just need a fairly interchangeable entry-level enterprise developer I might well hire a bootcamp grad rather than an MIT EECS major (who will cost more and may have less hands-on experience). The former may not grow in their job as much--or they may--but that's not really my problem if they help address my current need.
I “pivoted” to Enterprise Dev - and really restarted a stagnant career - in 2008-2012 (muddled my way through the recession)
Career projection for an enterprise dev is just like a BigTech dev to a smaller degree.
Junior engineer - learning the ropes and learning how to be a real professional developer. They will learn the then current frameworks and learn how to turn requirements into code. A boot camp grad has a leg up here.
Mid level - they can work mostly independently and by now they can take a relatively complicated feature from requirements to production following standard best practices. They may even be able to lead a team of developers working on a feature.
Senior - they can figure out what needs to be done (high ambiguity), lead multiple teams (scope and impact).
(After this I happened to pivot slightly and fell into a role at BigTech in the cloud consulting department.)
Senior+ - they can have an organizational impact and lead corporate technical strategy.
At higher levels, you need to know more about architecture and design. Even in large tech companies, being a good developer and knowing algorithms only distinguishes junior and a mid level developer
College wouldn’t help anyone after they pass the L5 level.
> learn how to turn requirements into code. A boot camp grad has a leg up here.
We did that in undergrad, most of my friends and I are leading small teams a few short years after graduation. We found that people without CS degrees can't handle ambiguity, and need a lot of hand holding to get things done, but maybe bootcamp grads are different.
> Senior - they can figure out what needs to be done (high ambiguity), lead multiple teams (scope and impact).
I am doing that, on AWS, one of the most important projects of the org, even though on-paper I don't have a lot of "experience".
I, the cs grad with an MSc, was the only one who could show that what the seniors wanted to do was [fundamentally] impossible - because this is very exotic CS knowledge. I delivered an approach - on time - that actually worked, when all senior engineers said it would take months. I was the only one who found a way out, and it leveraged all of my diverse - and at times exotic - knowledge and background.
> At higher levels, you need to know more about architecture and design. Even in large tech companies, being a good developer and knowing algorithms only distinguishes junior and a mid level developer
Ehhh, when you try to solve NP-Hard (or worse) problems, it is good to have people who can identify reductions and implement the right kind of algorithms. When the complexity (hah!) of the task is so enormous that exact solutions are impossible and you need to involve exotic stuff, neither design nor architecture can compensate.
To design a good system you need proper knowledge of what you are solving, no amount of engineering and architecture can get around a bad solution to a problem you don't understand.
>> learn how to turn requirements into code. A boot camp grad has a leg up here.
> We did that in undergrad, most of my friends and I are leading small teams a few short years after graduation. We found that people without CS degrees can't handle ambiguity, and need a lot of hand holding to get things done, but maybe bootcamp grads are different.
i don't think that bootcamp grads are different because of the bootcamp but possibly because they already have real world experience from before or were switching fields. they are also often older and more mature, but, most critically i wonder how many places teach how to turn requirements into code. my CS undergrad classes didn't have any of that. it's not "science" to solve peoples problems.
> how many places teach how to turn requirements into code.
I don't know. I know that where I did my undergraduate and msc, you either learned to do that, or you failed the courses. Fewer than 40% graduated on time where I did my undergrad, and a large portion outright quit in the first half of the first semester in grad school.
I did a year in the army, explosives-eod equiv, and it was a lot more chill than university.
> Ehhh, when you try to solve NP-Hard (or worse) problems, it is good to have people who can identify reductions and implement the right kind of algorithms. When the complexity (hah!) of the task is so enormous that exact solutions are impossible and you need to involve exotic stuff, neither design nor architecture can compensate.
I happen to have access to the internal guidelines for being promoted to a senior developer at AWS. It mostly talks about “scope”,”impact” and “dealing with ambiguity”.
It very possible for a mid level developer to be stronger than a senior technically. But that doesn’t put you on the promotion track.
I am an "L4" because I, on-paper, lacked the experience to be considered for L5 roles when I had joined.
I had been previously rejected from vacancies because, according to HMs, "I would find the role and responsibilities boring", and the company didn't want to "hire me and on board me, only for me to leave 3 months later".
> It mostly talks about “scope”,”impact” and “dealing with ambiguity”.
Yet, here I am, org-wide impact, and, deep in ambiguity, project-wide scope with no requirements and specs outside "do magic" to make it happen. So much ambiguity that no other team wanted this part of the project, and all managers were worried about us delivering, yet we are the only team ahead of the schedule.
I am not a back-end engineer, I don't know frameworks, I don't "know" cloud or front-end either. What I am good at is finding the right models to use to think about problems and then asking the right questions.
I understood what needed to be done because I understood what we were actually solving, I built the prototypes and showed that it works. The two actual SDE3s we have treat me as an equal and everyone else asks for my opinion and listens to me.
I’m in no way taking away or doubting your technical skill or knowledge. I’m saying according to the guidelines at Amazon and as far as I have seen at any other large tech company, it isn’t how you advance your career past a mid level developer.
I’m saying that you have to continuously demonstrate and document a history of showing that you can deal with increasing amount of scope, impact, and ambiguity to get promoted or do well on behavioral interviews at your next job.
From your description, the problem was well defined (we want to be able to do $x), you designed the solution. That’s not how “ambiguity” is defined according to the leveling guidelines. Being able to solve “complex” problems without help is L5 level behavior. That’s what you are describing.
> I understood what needed to be done because I understood what we were actually solving, I built the prototypes and showed that it works. The two actual SDE3s we have treat me as an equal and everyone else asks for my opinion and listens to me.
The difference between an L5 and L6 is not subject matter expertise either. There are plenty of areas where I have more and deeper subject matter expertise than L6s or L7s and I’m called in to talk to and advise customers based on my experience.
Have you read the internal definitions of “impact”,”scope”, and “ambiguity” as it pertains to the leveling guidelines? Your manager if he is decent should be able to help you.
I understand your frustration. But “what got you here won’t get you there”. It’s not about technical expertise.
My contact information is in my “About” section. From there we can exchange internal usernames.
I'll just add that a lot of the most senior people doing software today didn't major in CS and have gone through a variety of significant career pivots; CS is a pretty young field. I suspect a lot of people coming into the field today would be shocked at how circuitous a path a lot of the senior engineers at their company have followed.
The thing is, the big money isn't in being a highly skilled theoretical computer scientist who is a technical expert. The big money is in being someone who is able to execute an idea that he came up based on his knowledge in another area of expertise that is completely orthogonal to his technical skills.
Sure but at that point, someone is experienced and it becomes harder and harder to draw a line from their educational credentials to knowledge and abilities they've picked up over 10+ years of experience.
I posit that you can’t tell the difference between a mid level developer with 3-4 years of experience whether they learned on the job or from college or through a boot camp. If their company has a good mentorship program.
And on the other hand if they did go to a good college and ended up at a company without good practices, they will probably end up being “expert beginners”.
Also, I would be very hesitant to hire a software developer who only got experience at BigTech at a startup. They usually don’t have the breadth of experience that you need at an early startup.
If I need some basic plumbing work done, I'm far more likely to hire even a relatively inexperienced plumber than an MIT mechanical engineer with very little practical experience.
And if I just need a fairly interchangeable entry-level enterprise developer I might well hire a bootcamp grad rather than an MIT EECS major (who will cost more and may have less hands-on experience). The former may not grow in their job as much--or they may--but that's not really my problem if they help address my current need.