How much of the time is a backend software engineer actually writing code?

It definitely depends on your role, team, and company, but I agree with Lee's comment describing all of those activities as `writing code`. You're right though, there's usually a large disconnect in what Universities teach students and what skills those students are expected to have while on the job.

As a backend developer, much of my time is spent trying to understand the problem I'm trying to solve and how to best implement a solution. This requires a ton of soft skills (talking with stakeholders, planning work, researching technologies/methodologies, coordinating with other teams, etc) and less of getting into the weeds of the codebase. Once I've developed the best solution, I will spend the majority of my time actually implementing that in code. For other teams, I've spent a majority of my time writing code, but those roles were focussed primarily on reducing tech debt, migrating codebases to new environments, etc. which, while educational, can lead to burnout.

This kind of depends on the engineer, the company, what phase of life the company is in, etc. I spend a large majority of my time working with code. This is reading, debugging, testing, and writing. Personally, I bundle those up into 'writing code' because I can't successfully add new code without reading and understanding what exists. I shouldn't be shipping production code without writing tests, and doing at least some minimal testing of real use cases. As we all know, there will be bugs. And debugging takes time to read and understand what the intention is, and figuring out with testing in which cases it breaks.

All of that said, it still depends on how your team and projects are structured. Undocumented code isn't very useful. As a backend engineer, writing an API without documenting it doesn't help other teams understand what you're doing. As a new engineer though, no matter where you are, you're likely to spend a lot of time reading code, updating documentation, working on small bug fixes, and other tasks that are hard to justify putting engineering time on. It's not just because it's a bit of grunt work, it's a great way to understand the stack and tools that you're going to be working with. There's a lot to learn!

If you're in an early stage startup, you'll write a lot of code because you're creating things that don't exist yet while trying to get to a big, robust product. If you're in a large long-standing company, you're more likely to be in a maintenance role - adding to existing functionality and patching bugs. Ultimately, no matter what, you're going to spend a lot of time working with and communicating with coworkers. Someone (almost definitely not you) is going to decide what needs to be built, when it needs to be built by, and what the parameters are. You'll be in conversation with them throughout the project to ensure it meets the needs of the problem you're trying to solve. You'll spend a lot of time reviewing code. Deciding with coworkers which third party dependencies should be used. How to transition to new technologies when things start to get out of date.

Depending on how you frame it, this is all writing code. It's the underbelly of what it is to write and build something new. It's not always as fun as making something new, but it helps build something stable and maintainable that you and others can continue to add to without needing to rewrite something each time a new problem is faced. And in the end, it makes the time when you're working on a project much easier to reason with and solve in a reasonable way.

The industry has embraced agile more and more. I think the Scrum T-Shaped developer article is one of the best perspectives. The most value is added by reaching across disciplines. I'm also a big believer in Test-Driven Design. So, developers need to integrate testing into their approach & mindset. See https://www.infoq.com/articles/test-driven-design-java/