Those meetings come after you make the change where they tell you they actually expected the button would get smaller.
Don’t forget refinement where you describe your plan to add the “height: 80pt” rule (literally what the client wants), and then poker planning where you say it will be 1 point and the lead dev says 3 points and the other dev asks what is a point anyway leading to a time consuming discussion, and then the task gets scheduled for not next sprint but the sprint after, and then you do it and push your code, make a pull request, then during code review it is suggested you use tailwind instead but your project isn’t using tailwind because it’s some legacy PHP monster started by a junior who was just learning PHP, so now there’s a POC to consider using tailwind meanwhile the lead dev (who has a background in QA) designs a reusable “height engine” which uses rabbitmq to alert all worker nodes (there’s only one) about any changes to the height rules in mongodb. The height engine doesn’t include units so you have to hardcode if the client is expecting rem or pt. The product owner asks you in sprint review why this ended up taking a week when you said 1 point initially and the team agreed on 3. A team decision is made that all future CSS rule changes require a POC prior to implementation.
It's okay, breathe, the project manager isn't in the room with us now
The main thing I hate about inflated expectations in job postings and interviews is I keep expecting to do interesting and challenging work. And the jobs keep being like "make a powerpoint and summarize your results to someone that does not know what a number is".
I was interviewing a couple of months ago, and one of the in-person technical interviews wanted me to write, on a whiteboard, a function that took in a timestamp and calculated the angle between the hands on a clock set to that time. After I did that they wanted me to reverse engineer the linux "tac" command for files of unknown size that I could not store the contents of locally, resulting in probably the most sinful piece of code I've ever written.
What really gets my goat about it, is that out of all my interviewing companies, they were by far at the bottom of the list, and was really only interviewing to get negotiating power. My company had worked pretty closely with them, so I was well aware of the poor treatment and absurdly high turnover rate, so they were really in no place to be picky. My top choice company's hardest question was one of those basic college programming math questions where the answer is "use the modulus operator".
A lot of the time it's just an ego trip for the interviewer to show off how clever they are and to gloat over the interviewee when they can't figure out some really hard problem. This actually fits perfectly with the company having a toxic working environment. When you see these kinds of questions in interviews it's usually an indication that these aren't the kinds of people you'd want to be working with.
I am aghast at how difficult interviews are compared to literally every aspect of most jobs I've had.
