4 ms·

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

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

scarface_74 3y ago
> 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.
- PartiallyTyped 3y ago
  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.
  - scarface_74 3y ago
    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.
em-bee 3y ago
>> 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.
- PartiallyTyped 3y ago
  > 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.

scarface_74 3y ago

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

PartiallyTyped 3y ago
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.
- scarface_74 3y ago
  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.

em-bee 3y ago

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

PartiallyTyped 3y ago
> 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.