Question: I am about to change my job for an automotive embedded software company, doing ASIL D development. Such a company put a highlight in their SAFe framework.
Now, given my little experience, when working with "official" Scrum managements or "official" Agile methodologies in development, in couple of companies (the two last big ones where I worked) I found it was introduced frustration and acceptance in coworkers, as they lost the initiative, lost product innovation while working for years on the same project. Other engineer friends had similar opinions and "they live with it".

Either this was normal or not, only once I worked with constant enthusiasm, and that was fitting how I think. We were following the Kanban method, with small tickets, and implementing changes as required, turning out to be something like Extreme Programming. No complex tools for tracking, no coworkers paid to do only that, meetings were done only if there was a problem, everyone was feeling useful, and delivery estimation check was done with close contact with each other - and experience. We had relatively fast deliveries, enthusiasm and the like. But the company was also smaller.

As I am about to decide on this new job, I wonder: do you have any suggestions about which question I could ask their managers at the interview to check if SAFe is compatible with how I work? I am passionate about technology, electronics and reliability applied through it, not about management and confining creativity and engineering knowledge. I really feel clueless about how to discover this in advance, instead of discovering this after I start to work.

As you might imagine, I am not an expert in such management things, but I think that if something works, it should go smoothly for an engineer without spending weeks to study such methodologies and not working. So I am also searching for a way to look at these things with the right perspective.

Answer: 
SAFe is a framework, not a proscription. That said, there are some fundamental things which, if you're not doing them (correctly), you're not doing Agile.

I understand your frustrations with an Agile process, especially if done badly, but if you work with it, a lot of the pain is removed (the "big bang" approach to delivery, weeks of forced "death march" overtime, the screaming and blamestorming when things go wrong, management hiding behind "you didn't tell us it would be late", etc).

It's not perfect of course; It can be really frustrating to be pulled out of an intensive, head-down code session for some seemingly trivial ceremony (an Agile term for a regular meeting). And when the "open and transparent" is used by management to gather info for bashing the team....

I understand where you're coming from, but I've also over the years worked with some really stubborn people who cannot, will not, start properly using source control, an IDE (software development environment) or some other tool or process (testing?) that we, as a profession, now consider de rigeur.

Do you like the job? Is the money good? Other aspects? Take it or don't based on those.
My company rolled out SAFe based on the success of a grassroots agile movement.

The good thing about it was bringing more of management into feeding us work in a more agile way. i.e. by maintaining a prioritized backlog and at least trying to do small features with more frequent feedback.

The bad thing about it was it had a tendency to centralize decision making and added a lot of bureaucracy/overhead. When I was a scrum master during the grassroots phase it mostly meant leading the meetings. Our scrum master now is doing administrative work at least half time and often full time. Our day to day is mostly the same, but our month by month feels a lot less efficient. For example, we are asked to produce 10 week plans when they almost never last past 5 weeks. I think a lot of our day to day is helped by the fact we did grassroots first, and still insist on a lot of the autonomy that provided.

Were I interviewing for a job at any "agile" company, whether SAFe or not, I would ask about their planning process from when someone has an idea to when it is deployed to production. That will give you an idea of how much teams are autonomously executing in small increments to a well-communicated shared vision, versus being top-down managed.