They will work more hours for less money. This is nothing new. My first job out of university in the early 1990s was for one of the "big" consulting firms. 50-60 hour work weeks were the norm. I made decent money (they paid overtime) especially for a first job, but I wouldn't do it at my age now with a family and kids.
Lack of manager ability to measure productivity based on anything else. Between POs, BAs, business representatives, and IT managers there are a lot of people who don't seem to be able to grasp why two relatively simple to describe tasks can require such vast differences in time. So it becomes hard for them to judge if their developer is wasting their time or not (and let's not even begin on overall lack of trust to begin with), so the only fall back measure is if they have their butt in the seat and appear to be working. And even if you are lucky enough that everyone you directly deal with either understands the basics on why sizing varies so greatly or able to accept it without question, you still have to deal with middle managers walking the floor who measure productivity the same as they would in a factory. And if you are lucky enough to not even have this problems, you still have to deal with cultural norms set in party by all the jobs which aren't as lucky.
Had a lowball offer from a company once - had some friends working there. I could see from some earlier code that some really basic web knowledge was being overlooked. I won't go in to details, but... this was something I'd pointed out to one of the managers there (met at a local meetup). Fixing it then would have taken about 2-3 hours, scanning all the code to ensure it was in sync. Instead, the problem spread as they grew, and it's harder to fix when there are dozens of staff and thousands of files in use vs 5 staff and a dozen files. It became a 'this has to be fixed in order to close mega-deal X integration with company Y', and it took multiple devs several weeks of full-on effort to rectify everything.
How do you quantify that? "Please, take my advice, doing this 4 hours of work now now will save you >$50k and weeks of opportunity cost in 4 years". Generally people don't seem to care.
As people are noting on this thread, startups are their own thing. During my startup days, we were always the next sale or funding round away from going belly up. We pulled late hours to get in the latest features for our president to "sell" to investors.
Data import processes often seem to get shuffled to people usually least prepared to understand how to handle them.
2 anecdotes:
1. worked someplace years ago who would take in customer data, transform it in to our structure, then put in to mysql (2004 mysql). larger projects... this ended up taking 24 hours in some cases. I spent some time (a few hours), and had the whole thing working in under an hour. Working with a couple other folks there they got it down to around 20-25 minutes. The big secret was .... dropping indexes, importing chunks in to memory (vs disk), then copying the memory table to disk after a chunk. This was first met with "that can't work... we've already optimized everything... etc". Until it was demonstrated.
2. Colleague worked at a company which was primarily email marketing. They'd take in email lists, "import" them (which created some related metadata records, etc). The guy who wrote this importer had 'rewritten it to be faster' a year earlier, and larger imports (we're talking like... 10k emails) were taking days. Onboarding a client of 30k emails would take 2 weeks. It was literally insane code. My colleague rewrote the whole thing to work the 30k emails in under an hour, documented the code, had tests demonstrating weird edge cases... "Can't trust it - original dev needs to review it first". He (my colleague) was part of a group of people who was let go a couple months later (and was also approaching 40).
The phrase "big data" was also taking hold as a buzzword around the time of incident 2 (2 years ago maybe?). People think anything that can't fit in to excel is somehow 'big data'.
To be fair, I'd say this is only true if "excel" is generalized to "the largest non-distributed-computing tool they're personally aware of".
Granted, that may usually be a spreadsheet, but at least in the tech industry, people do know of DBMSes. They just happen to think an affordable single server is an order of magnitude smaller than is actually achievable, even if it's an order of magnitude larger than a spreadsheet.