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: 
Out of point: My opinion on SAFe is that it is not "agile" but something that tries to reconcile management and product management with agile team.

On the point: The issue is that like for any methodology the company can say "we're doing X" or "we're working with Y" and when you join you understand that they don't understand either X or Y and are just buzzwording (intentionally or not).

Start by researching about SAFe to better understand what problems it tries to solve and how it works. Then when interviewing, don't ask about SAFe, but how they effectively work with specific questions:

> 
> How much planning is done on project, is it long term planning (>1y),
> mid term planning (3~6 month) or short term/scrum planning (1~4w)?
> 
> 
> How are deliveries done? Which system is used? What tools? How long
> does it takes once a task is finished to be delivered?
> 
> 
> 

With this you'll know two things: If they want to use SAFe do you want to work with it. Are the process effectively in place what you seek.
This has absolutely nothing to do with SAFe or Scrum or Kanban or Extreme Programming.

To start with, lots of companies claim to be using one or more of these methods, but you see a couple of things. One is that they are frameworks and there are multiple ways to do them within the bounds of the framework. Another thing that you see is that the intent of the framework isn't understood and the organization does them wrong. Just the fact that they claim to do them, whether it's in person or in a job description or elsewhere, doesn't really mean that much.

You know how you have worked in the past and have been effective. You can ask questions about how these organizations work - is work pushed or pulled, how much time is allocated to innovation or R&D work, what tools are used and how do they fit into the development process, how much time is spent in meetings on a regular basis, how often is work delivered and integrated, and so on.

Just don't worry about what process models or methods or frameworks that they claim to use. Focus on what's important to you and ask these types of questions to everyone, from the hiring manager to the leads to the individual contributors that interview you. Maybe even ask the same questions to multiple people, especially if they are on different teams to get a feel for how different teams in the same organization may be structured or go about their daily work.