The problem is always the marketing, management, and c-suited who have never written a line of code in their lives but want to dictate the terms of a feature.
An example might be a new frontend page
On the surface there is a business use case for it, a client wants it asap. The sales and marketing get that feedback and push it along to the developer to estimate...now here is the issue
Sometimes it's easy and no big deal, you write a backend model that wraps a hopefully existing db table and a frontend to wrap that model. Hopefully you have some wireframes or even a crude mspaint example of what they expect. Sometimes you don't and just copy a similar page and adapt.
The issue comes when that isn't the case. Maybe the page they want ties six tables worth of data together and requires a mother of all stored procedures or a hard coded query in the backend somewhere. Maybe what they are asking has no symantic connection at all and you need to create six different lookup ID columns, maybe even what they want like a graph of complex data or a docx generated in JS is just a bad idea for page performance etc. Maybe the feature breaks the convention of your codebase entirely and becomes a security concern or requires a major package like react or flask to be updated to get a function that would simplify it. Any number of things can go wong and eventually do.
This all comes down to the company. At a good company developers and project managers have the freedom to express that the estimate for a feature or the scope or even rational for a feature is going to be complex and take time you will need to find. At big companies this means working on it while being in scrums or sprint meetings and quarterly meetings and brainstorming meetings and whatever the hell the sprint bingo or poker stuff is. A good management team will understand what they don't understand and give your team the bandwidth they need to do their job well.
At a bad company your estimate is ignored or shamed in some way and you are forced to lie which is often the case and say everything takes 2x as long to finish just in case there are crazy issues you didn't understand. The management will tell the cline yup front that a feature will only take a week before even talking to development estimating based on a similar ticket to snag a sale for themselves and when they are wrong they push that blame onto engineering to save their skin progress reports. If the feature doesn't make sense as described by the client to marketing and sales and you have no recourse then you end up creating bloated and needlessly complex software that is essentially designed by somewhat unnatural selection and over time you get random api endpoints and UI/UX sins that snowball into what we usually call "typical banking software" outlook is also an excellent example of this problem though.
Sadly the honest developers tend to go over budget or estimate at these companies and management typically only sees that as a data point in their tracking software and usually ask your micro-manager or PM to crack a whip without any context for why and how. Its invariably the engineers fault because every level beyond them has exponential disconnects as to what the true work of writing software requires in your codebase. They have no understanding of technical debt or limitations on front ends/backends.
Occasionally a new hire from college just can't cut it but I've never seen it happen because someone is genuinely not smart enough. If you just try in Ernest you will succeed somewhere but if you get fired for not delivering deadlines don't beat yourself up immediately, ask yourself what you were task to do and consider how realistic that was...and realize there are plenty of other jobs out there who will respect your opinion.