Do engineers at FAANG choose what problems they want to solve? At places I worked, it was more of management task to choose problems to solve. Developers just worked on tasks they were given.
If all you do as a developer is just work on tasks given to you then you aren't going to rise very high in the ranks in any tech-forward company, FAANG or not. Sure you can make a decent career out churning tickets given to you by someone else, but you'll run into a glass ceiling pretty quickly. The tasks don't just appear out of thin air.
A key part of being a senior+ engineer anywhere is the initiative and autonomy to identify problems, quantify costs and benefits, and work with management and stakeholders to come up with solutions that balance cost, complexity, schedule, and quality.
Much of my work as a staff engineer is working with engineering, product, and business leaders to collectively identify what our biggest challenges are and how we should go about attacking them from the engineering side given all our resources and constraints. And then spearhead the implementation to get projects going the right direction and overseeing more junior team members.
The actual coding is the "easy" part that comes after first defining the problems and specifying solutions and wrangling the competing needs of the business. Engineering should have a seat at that table since we're on the hook to build (and maintain) it, after all.
I agree with you up until the cliche "code is the easy part".
People say this at the same time that they complain that people with 10 years of experience can't even solve FizzBuzz.
The amount of badly architectured, buggy code I've seen in a couple of decades working with software tells me that "code is the easy part" is an absolute lie.
Writing good code that's well tested and mostly just works, while being efficient, is such an extremely difficult task that I am not sure many developers in the world can do it. So, no, code is not the easy part, it's only the part where you can probably escape accountability (as no one will be able to tell) unless you have good devs in your team that can properly code review (which is also very rare).
I mean, code is both the hard and the easy part. I can write the code to get good code, or I can spend more effort on finding the right problems to solve and let others write shitty code.
It hurts to let people do that, but ultimately shitty code still works, while having solved the wrong problem means that all the work goes down the drain.
¿Por qué no los dos? - find the right problems to solve and write good code (or insist on good code being written) to fix them? Because bad code (unless it's throwaway code) will quickly become a problem all of itself...
