u/Huge-Leek844

I work at a large automotive company on customer-facing projects. Customers come to us with edge cases where the system fails.

My job is to investigate, find the root cause, propose a fix, estimate the effort, assess the risks, present to stakeholders, and help decide if it's worth doing.

I'm good at it. I trace failures to their physical causes. I scope solutions from quick parameter tweaks to full architectural redesigns. I present tradeoffs for my module and dependent modules. I coordinate across departments. I assess business viability.

On paper, seems i am becoming a senior engineer. Here's the problem: the answer is almost always "not worth it." Too expensive. Too risky. And i agree to be honest. Wait for next generation. The customer gets a report. I get the next ticket.

I'm building every "senior" skill except the only one that actually matters on a CV, the proof that I built something end-to-end.

How do you get out of this loop? Shall i update my CV and leave? Shall i implement the proposals but as projects?

Hello everyone,

I’m in my first year as an embedded software engineer. My background is in electronics but i work as software engineer in automotive.

Lately my tickets are getting weirder and weirder.

Current injection I & Electric static discharge testing: Causing problems in the clock, and other parts.I cant really reproduce.

Thermal anomalies: Temperature spikes overheating the system once, then never again.

Errors that occured once in weeks of field testing.

As a software guy, debugging this is brutal. My current approach is just asking: "How does this physical test change the inputs to my code?"

My questions for the veterans:

Do you actually study the EE side, or do you just learn to deal with these as they pop up?

If I should study, what fundamentals do I need? (EMI/EMC, Signal Integrity?)

Any recommended books or resources for a software dev drowning in hardware issues?

Thanks!

Hi everyone,

I’ve been working for the past 3 years at a Tier 1 automotive company as a radar signal processing engineer.

To give you an idea of my typical workload, here are the types of tickets I analyze:

Investigating how mutual interference between sensors or overlapping spectrums degrades the SNR, and applying countermeasures to prevent ghost detections and false positives.

Root-cause analysis of tracking dropouts or track flickering. For example, diagnosing instances where a pedestrian is occluded, two cars are merged, multipath.

My issue is that when I solve these tickets opened by the tracking team for example, my work ends at the Point Cloud validation. I do not develop or write the downstream tracking or fusion algorithms.

Given that my practical experience is locked before the tracking/fusion code layer, how should I position my profile to avoid being labeled as radar engineer.

Thanks for any insights.

Olá a todos,

Trabalho há 3 anos numa empresa automóvel Tier 1 como engenheiro de processamento de sinal de radar.

Para terem uma ideia do meu dia a dia, analiso tickets como:

• Investigar como a interferência mútua entre sensores degrada o SNR e aplicar contramedidas para evitar deteções fantasma.
• Analisar como o posicionamento físico e os materiais do para-choques afetam a propagação das ondas, causando atenuação ou clutter.
• Análise de causa-raiz em falhas de rastreio (tracking dropouts ou flickering), como peões oclusos, fusão de veículos ou multipath.

O meu problema é que o meu trabalho termina na validação da Point Cloud. Não desenvolvo os algoritmos de tracking ou fusão que vêm a seguir.

Quero fazer uma transição do setor automóvel para a área de Perceção em Robótica.

Dado que a minha experiência prática fica retida antes da camada de código de tracking/fusão, como devo posicionar o meu perfil para evitar ser rotulado apenas como "engenheiro de radar"?

Obrigado pelas vossas sugestões!

Hi everyone,

I’ve been working for the past 3 years at a Tier 1 automotive company as a radar signal processing engineer.

To give you an idea of my typical workload, here are the types of tickets I analyze:

Investigating how mutual interference between sensors or overlapping spectrums degrades the SNR, and applying countermeasures to prevent ghost detections and false positives.

Analyzing how physical placement, fascia, or bumper materials affect the wave propagation, causing attenuation or clutter.

Root-cause analysis of tracking dropouts or track flickering. For example, diagnosing instances where a pedestrian is occluded, two cars are merged, multipath.

My issue is that when I solve these tickets opened by the tracking team for example, my work ends at the Point Cloud validation. I do not develop or write the downstream tracking or fusion algorithms.

I want to pivot away from strict automotive radar into Robotics Perception.

Given that my practical experience is locked before the tracking/fusion code layer, how should I position my profile to avoid being labeled as radar engineer.

Thanks for any insights.

Hey everyone,

I’m looking to understand how roles are structured across the industry right now, particularly in automotive, defense, aerospace.

I want to know if it’s plausible to stay on the R&D/Algorithm Design side while handling your own high-performance C++ implementation, or if the industry has completely siloed these into separate teams.

My questions for the community:

How common is the "hybrid" role? Do R&D engineers who design the state-space models, estimation filters, and kinematics loops also get to write the high-performance C++ code and profile the SIMD/spatial optimizations? Or there is hard silo where the algorithm guy just hands a MATLAB/Simulink script over to an embedded software team to translate?

If you are working on these high-level algorithmic pipelines, are you still expected to be in the trenches dealing with low-level RTOS task scheduling, DMA configuration, and debugging hardware registers over I2C, SPI, and UART? Or is that infrastructure layer typically isolated by a dedicated BSP (Board Support Package) / firmware integration team?

I love the math, tracking estimation, and algorithmic optimization, but I want to avoid getting stuck purely as a "hardware janitor" fixing low-level peripheral timing bugs, while also avoiding being an academic who just writes slow prototypes.

What is like in your companies?

Thank you

Hey everyone,

I’m looking to understand how roles are structured across the industry right now, particularly in automotive, defense, aerospace.

I want to know if it’s plausible to stay on the R&D/Algorithm Design side while handling your own high-performance C++ implementation, or if the industry has completely siloed these into separate teams.

My questions for the community:

1. How common is the "hybrid" role? Do R&D engineers who design the state-space models, estimation filters, and kinematics loops also get to write the high-performance C++ code and profile the SIMD/spatial optimizations? Or there is hard silo where the algorithm guy just hands a MATLAB/Simulink script over to an embedded software team to translate?

2. If you are working on these high-level algorithmic pipelines, are you still expected to be in the trenches dealing with low-level RTOS task scheduling, DMA configuration, and debugging hardware registers over I2C, SPI, and UART? Or is that infrastructure layer typically isolated by a dedicated BSP (Board Support Package) / firmware integration team?

I love the math, tracking estimation, and algorithmic optimization, but I want to avoid getting stuck purely as a "hardware janitor" fixing low-level peripheral timing bugs, while also avoiding being an academic who just writes slow prototypes.

What is like in your companies?

Thank you

Hey everyone,

I hold a Master’s in Robotics and Control with a thesis focused on Model Predictive Control (MPC). My true passion is GNC, but due to the limited number of open positions, I took a job in radar signal processing and perception for autonomous driving.

Right now, I’m struggling. I have zero passion for radars. Because of this, I'm finding it incredibly hard to motivate myself to study and improve after hours; it feels like I'm burning energy on an area I just don't care about. I want to build a strong career and I have plenty of drive to devote time and energy, but I need to channel it correctly.

I want to bridge the gap between where I am and where I want to be. How should I approach this situation?

• How can I tie my current work in radar/perception (e.g., Kalman filtering, state estimation, tracking) into high-level GNC skills? What should I focus on studying?
• What kind of advanced GNC/MPC personal projects actually move the needle on a resume when you already have a Master's degree?
• How do I stay motivated to upskill when my 9-to-5 feels disconnected from my career goals?

Would appreciate any advice.

Thanks!

Hey everyone,

I’ve been with the same company for about 4 years, but 8 months ago I got moved to a new project and it was a massive reality check.

I came from a team with a very slow pace and, without even realizing it, my brain was starting to rot. I was just an apathetic "ticket closer." Now that I’m in a high-performance team with a much faster pace, I feel like my brain finally woke up (lol).

The big lesson I wanted to share with anyone feeling stagnant is that legacy code is no excuse for apathy. We often use the "it's just old code" excuse to do the bare minimum, but there’s so much you can learn there. I started actually reading the scripts I was running instead of just hitting Enter, and I began looking at existing CI/CD pipelines to figure out how I’d write them from scratch or how to optimize them.

I stopped waiting for tasks to fall into my lap and started proposing automations and improvements myself. The funny thing is, since I flipped this switch and stopped being inert, my mental health has improved immensely. Feeling like you’re actually evolving and understanding the "why" behind things is what keeps you sane in this industry.

I’m writing this because I see a lot of posts on Reddit from people who seem to be on autopilot. If you feel like you’re stagnating, try changing your approach, even if the project itself isn't motivating. Changing your mindset is possible, and sometimes the problem isn't just the project, it's how we choose to look at it.

Boas pessoal,

Estou na mesma empresa há 3 anos e meio, mas há uns meses mudei de projeto.

Eu vinha de uma equipa com um ritmo muito lento e estava a estagnar. Estava naquela fase de ser apenas um fechador de tickets apático. Agora, numa equipa com outra pedalada, sinto que o meu cérebro finalmente reativou. Ainda é um projeto "legacy".

A grande lição que tirei e que queria partilhar com quem se sente estagnado é que o legacy não é desculpa para a apatia. Muitas vezes usamos o facto de o código ser antigo para fazermos só o mínimo, mas dá para tirar muito sumo daí. Comecei a ler os scripts que executava em vez de só carregar no Enter, comecei a olhar para as pipelines de CI/CD e a tentar perceber como as escreveria do zero ou como as podia melhorar. Quando há um bug, vou mais a fundo. O meu colega teve um problema x? Vou estudar.

Passei a ser eu a propor automações e melhorias em vez de ficar à espera que o trabalho me caísse no colo. O mais engraçado é que, desde que mudei este chip e deixei de ser inerte, a minha saúde mental melhorou imenso.

Escrevo isto porque leio muitos relatos aqui de malta que parece estar no automático. Se sentem que estão a estagnar, tentem mudar a abordagem, mesmo que o projeto não pareça motivador. Mudar de mentalidade é possível e, às vezes, o problema não é só o projeto, é o modo como olhamos para ele.

Hi all, I’ve spent the last 3 years working on Radar Perception for a legacy automotive project in Germany. My background is an MSc in Robotics & AI. Currently, I spend my time analyzing point clouds and SNR distributions to debug failures. It’s mathematically complex, but I’m not implementing any models or designing systems. I feel like I'm becoming a "PowerPoint Engineer" who knows a lot about noise but isn't building the future of autonomy. I want to move into Applied ML/Autonomy, but I’m worried my 3 years of "analysis" don't count as "development experience." Does it make sense to build a portfolio of ML/Robotics projects applied to Radars to prove I can actually code, or will recruiters only care about my work? Is this a good path for applied ML or i am kidding my self?

Olá a todos,

Sou engenheiro de processamento de sinal em radar (point clouds, análise de espectro, muito debugging em sistemas legacy) e quero fazer a transição para ML aplicado à robótica.

Tenho boa base de matemática + experiência com dados reais de sensores, e acesso a dados + a um repo interno com projetos de ML.

A minha dúvida principal: vale a pena investir tempo a reimplementar esses algoritmos de ML e fazer projetos pessoais, ou isso não chega para conseguir a transição?

O que fariam no meu lugar?

* Ficar e construir projetos em paralelo? * Tentar mudar internamente? * Considerar um mestrado?

Se alguém já fez uma transição parecida, o que é que fizeram?

Muito obrigado.

Hello all,

I’m a radar signal processing engineer (point clouds, spectrum analysis, lots of legacy debugging) and want to move into applied ML for robotics. I have a masters in robotics and AI.

I’ve got solid math + sensor data experience, and access to real data plus an internal repo with ML projects.

My main question: is it worth spending time re-implementing those ML algorithms myself plus doing side projects, or is not worth it.

I can dedicate 2 hours a day for the projects. I am very serious about leaving, but i lack direction.

Would you:

• Stay and build projects on the side?
• Try to pivot internally?
• Or consider something like try to do research with a professor?

If you’ve made a similar move, what actually helped you break in?

Boas pessoal,

Estou numa situação que imagino ser comum a alguns de vocês: sinto que estou a estagnar no meu emprego atual. O stack é legacy, os desafios técnicos são nulos.

Para combater isto, tenho estado a dedicar-me a projetos pessoais. A minha questão é: até que ponto é que as empresas em Portugal valorizam isto em vez de experiência "real" em contexto de trabalho?

E mais importante: como é que vocês demonstram estes projetos no CV de forma profissional?

Gostava de ouvir as vossas experiências sobre se isto já vos ajudou a dar o salto para algo melhor.

Obrigado!

Hello,

I have 3+ years of experience in embedded systems and autonomous driving. My current role involves a lot of real data analysis and I work closely with repos containing ML code, but my actual daily output is not ML-focused (mostly C++/system-level work).

My goal is to pivot into a Machine Learning Engineer (MLE) role. I’m at a crossroads regarding how to bridge the gap without being dishonest on my CV.

Are side projects worth it for someone with 3+ YOE? Or do hiring managers see them as fluff compared to professional experience?

How should I showcase them? I don't want to lie and claim ML was a primary duty at my current job, but check out my GitHub feels like a weak pitch for an experienced dev.

Since I’m already in autonomous driving, would focusing on Edge ML / TensorRT / Model Optimization be a more realistic pivot?

Did you rely on personal projects, or did you find a way to bring ML tasks into your day job to get it on the resume?

Thank you

A minha empresa está a trabalhar neste produto: "The vehicle recognizes user needs in real time: For example, when a call comes in and a passenger picks up the phone, the system automatically reduces the music volume and closes the window - seamless and intuitive"

A minha pergunta é porquê? Imaginem os edge cases disto. O cão com a cabeça de fora, por exemplo.

edit: pessoal, a demo foi descrita num post do LinkedIn. Não estou a partilhar informação privada. Não é um rant, nem sequer estou a trabalhar nesse projeto.