Cypress or testcafe?

Go for it
You were interviewing at other places for a reason. If the current place hasn't done anything to address those concerns go try something new. More varied experience will make a you a better dev and (more importantly) a better person

Start with a problem
Then come up with a solution
AI might solve it, might not.

Sounds like you're doing at least 4 different roles. Even for one role you're probably paid about half of what you should be.
Why is there no investment?
How is the software monetized? Is there a monthly subscription? Start from there and work out how much should be put back in. If it's not enough then leave.
Make it clear that if there isn't (continual) investment then the product will slowly die.
They got very lucky with you!

Yep
Major problem with AWS has been complained about for years

Flutter is the new hotness for mobile apps. Cross platform with Android and iOS, it can also be a website!

1-1s should focus on anything BUT your current tasks. Management stuff, company performance, your dog, Gloria's wierd aroma, whatever. You should bring topics to discuss, even personal ones if your relationship is good.
I personally take the time to focus on me and how the company is going to make me better. Upcoming training, upcoming projects, conferences (speaking or attending), etc.

A lot of people don't like to ask for help as they think people will think they are stupid. Unfortunately some people will think that. Although if that does happen you know it's not a good place to be! I've been lucky to work with some great people where I could feel comfortable enough to ask anything. It's so much more productive!

Yep, and they're suing someone for 'hacking' them

Listen to your team.
Find out individual strengths and weaknesses and help progress them.
You don't need to know everything (This is really hard to accept).

How can you not get time complexity from functional code?

Lots of pairing and mobbing where they are driving.
Lots of documentation, diagrams, etc.
The more they do it and see it, the more comfortable they will get

Lucidchart, nice collaboration

I'm not sure each discipline needs to know as much as the other. I like the concept of a T-shaped person where the vertical line represents deep knowledge or specialism and the horizontal is the broad knowledge of everything else needed to build and operate a product (yes I'm including DevOps tasks with this too).

Why does the backend need to know it's consumers?
Or do you mean developers?

If you're using GitHub there's an option to request changes instead of approve

What can they do if you don't approve?

Either accept your feedback or the process is broken and don't bother

Try the schedule function and set the time to 9:00 on morning they get back (or maybe spread it out a bit).
You've still sent the info but they don't get it till they're in

Aws has a free tier that expires after a year on a newly setup account. Not sure about Azure (they confuse me and I accidentally got ran up a bill around 50$ for their function stuff).
Most tutorials will use the free tier or if not it shouldn't be more than a dollar or two

Wouldn't trying this have been quicker than asking the question?

https://youtu.be/HMqZ2PPOLik

Constructively
Refer to any coding standards your company has.
Provide examples where something could be better.
Provide positive comments as well.
Try and make it a conversation.

You want to pay for stuff you don't use?

Halt and catch fire is much better.

Or Silicon Valley

They don't care about you past the point that you get the job done.
My advice to every is never accept the counter offer. The reason you wanted to leave will still be there if you stay.

There was a javaslang but they had some issue with Java people so they renamed it to vavr.

@KDSBest quite the contrary.
I like the debates and hope everyone learns something, even if they don't agree with it.

@KDSBest I can tell we're not going to agree, and that's cool.
👋

@KDSBest no offense but I dread the quality that is going in if you're quickly merging things.
There is no way you can merge a 20 line change and a 2k line change in the same amount of time and keep up the quality.
A good indication is how much time is spent fixing defects or doing support as opposed to building new features.

@KDSBest why would I want to read the commit history?
If there are 50-200 people committing to one repo I think the chances of a merge conflict are much higher the longer the code is sitting locally, even worse if that's a 2k line merge. Faster it gets merged (ie faster review) the less conflicts there will be and less time wasted. Small PRs is a great way to do this.

I've started to refuse interviews that do that. If they're paid, fine. Otherwise no chance