Nokia

Good salary, especially initially if you negotiate well and perform.

Hybrid or full remote work.

Helpful and professional coworkers.

Additional benefits like some bonus money for food to order or get from the cafeteria or healthcare.

Flexible hours.

Good work-life balance, as long as you perform.

Onboarding. Micromanagement. Too many changes to the way of working. Constant issues with the environment/build system. Hard to become an asset with many experts with tens of years of experience. Hard to obtain code area ownership. Internal politics. Complex projects with many dependencies, which can end up bottlenecking deliveries and creating additional work with troubleshooting. People are trained more often in DEI than in being up to date with the latest technology or getting chances to sharpen their skills. Meeting-driven development.

Don't gaslight people to make them accept lower salaries or no raises. It's a temporary gain, as you will eventually lose people who have gained expertise in the complex toolset, products, and systems you have in place.

Focus on technical improvement. Give people ways to sharpen their skills, expand their knowledge, and advocate for doing so. Some parts of work can keep a developer out of the codebase or programming for long periods. While expecting a student to keep studying after their job is understandable, expecting the same from a full-time employee is not.

Rather than having so many systems in place to control and monitor progress or effectiveness, create systems that help your employees grow, become better at what they are doing, and expand their knowledge or expertise. Monitor this rather than KPIs.

Make sure you have a proper onboarding system in place rather than whatever anyone will come up with. I was left with someone who had issues setting up an IDE and build system and worked with a bad setup for months before I learned that some settings are detrimental and once you change them, you can synchronize with the remote six times as fast.