2 answers
Jacob
Student
Long Beach, California
3
Questions
Asked
689 views
What does a typical day look like in this field?
I am currently in Long Beach Job Corp, and will be studying automotive. I have a few weeks to see if I am still interested in this field, and if not, I can switch to a different field. I just want to know what a typical day looks like.
#automotive #engineering #career
Login to comment
2 answers
Serv Goyal
Supply Chain Management
1
Answer
San Jose, California
Updated
Serv’s Answer
Hi Jacob, being an engineer in the automotive field can be very rewarding. There two common types of jobs for automotive engineers.
- Design Engineers - Here you maybe part of a team that designs various parts of a car - it can be from interior or exterior of the car - some part of the engine, transmission. Normally you would using special CAD (computer aided design) software to design a part on the computer, and getting team's feedback, suggestions - it can be very a collaborative experience. You maybe involved in testing the parts you design to make sure it meets all the safety and other requirements. You will also frequently talk to manufacturing engineers, who are responsible for making the parts you design. You will learn about how the part you design fits together with parts other engineers are working on - so normally its a very team oriented job.
- Manufacturing Engineers - Here you will be responsible for making some of the parts of a car - You maybe learning and setting up a large machine to make high quality parts in least amount of time - Parts maybe made from plastic, steel, aluminum, etc. How a particular part is made is called 'Process'. So you can choose which part of a car interests you and focus on learning about that process - and become an expert. Ultimately manufacturing engineers are responsible to make sure good quality parts are available to assemble the car on time. I worked as a Process Engineer at Toyota for about 6 years and it was a very rewarding experience.
If this interests you, I suggest you watch some youtube videos on various automotive processes, such as injection molding, painting, sheetmetal stamping, assembly, etc. see if something catches your interest. You can also learn Google Sketch, a free tool to create parts on your computer.. to give you a feel for CAD software - there are also other softwares available for your learning.
Kudos for the response!
Sumitra Biswal
Very insightful advice!
Sheila Jordan
I'm not really familiar with Job Corps, but isn't it more of a vocational program than academic? I'm sure it's possible to get to work in design and manufacturing engineering via the program, but I would have thought it's aimed more toward the sort of automotive maintenance skills needed in a local garage or repair shop, rather than the more in-depth engineering skills needed by a major design and manufacturing centre.
Joseph Neilson
Jason Stone
Systems/Electrical Engineer
6
Answers
Greensboro, North Carolina
Updated
Jason’s Answer
I’ve been both an automotive test engineer and an automotive software systems engineer.
As a test engineer there was a lot of organizing information for test builds. In order to run a test, some test parts are needed (or even a whole prototype vehicle) and then shop work for mechanics to put it together. The fun part may be actually running the test but it may also be stressful. This could be any kind of driving situation that you try to focus on and repeat. Some things can be sort of silly: I once was in a climate chamber to see if I could hear an o-ring leak when the engine started in arctic temps. But I've also driven over a mountain to see if a fully loaded vehicle overheats on the way up and brakes well on the way down - all the while making sure the correct data is captured. I also road in back of a German car at 100+mph for a full tank of gas also to check temperatures. In between, this can be a lot of walking back and forth between your desk and the shop to check parts and progress as well as meetings to figure out what needs doing and how to organize all the people and parts involved. Maybe a little math here and there in reports to compare results to theory and explain what happened. I was surprised early on how little of my classwork I could actually apply. But it was likely needed so that I understood what to look for and what happened.
Then I moved to software. There I was surprised that most of dealing with software is not coding. There needs to be a lot of documentation so that all people involved understand what is requested of the software at several levels. What should the driver experience in the end? What should each ECU do in order to achieve that? What should it do when inputs fail? How should it determine if inputs fail? How to verify that this all came out right? Then there is all the aftermarket and sales information so that people can understand how to configure things if that is an option or just plain advertise the feature properly. As software gets more complicated there are many meetings about how to approach a problem or new feature or whether to do it all, then how to coordinate the work so that all the parts come together for production and aftermarket. Then handle any problems or complaints after that. Even if you’re the coder, you can’t avoid this completely. So the day’s are often filled with these meetings or writing docs or presentations to prepare for these. Lately there are also documents about the safety analysis and cyber security measures. A lot of people that understand the software don’t understand the vehicle. A lot of people that understand the vehicle don’t understand software. So I spend time bridging the gap as a systems engineer.
As a test engineer there was a lot of organizing information for test builds. In order to run a test, some test parts are needed (or even a whole prototype vehicle) and then shop work for mechanics to put it together. The fun part may be actually running the test but it may also be stressful. This could be any kind of driving situation that you try to focus on and repeat. Some things can be sort of silly: I once was in a climate chamber to see if I could hear an o-ring leak when the engine started in arctic temps. But I've also driven over a mountain to see if a fully loaded vehicle overheats on the way up and brakes well on the way down - all the while making sure the correct data is captured. I also road in back of a German car at 100+mph for a full tank of gas also to check temperatures. In between, this can be a lot of walking back and forth between your desk and the shop to check parts and progress as well as meetings to figure out what needs doing and how to organize all the people and parts involved. Maybe a little math here and there in reports to compare results to theory and explain what happened. I was surprised early on how little of my classwork I could actually apply. But it was likely needed so that I understood what to look for and what happened.
Then I moved to software. There I was surprised that most of dealing with software is not coding. There needs to be a lot of documentation so that all people involved understand what is requested of the software at several levels. What should the driver experience in the end? What should each ECU do in order to achieve that? What should it do when inputs fail? How should it determine if inputs fail? How to verify that this all came out right? Then there is all the aftermarket and sales information so that people can understand how to configure things if that is an option or just plain advertise the feature properly. As software gets more complicated there are many meetings about how to approach a problem or new feature or whether to do it all, then how to coordinate the work so that all the parts come together for production and aftermarket. Then handle any problems or complaints after that. Even if you’re the coder, you can’t avoid this completely. So the day’s are often filled with these meetings or writing docs or presentations to prepare for these. Lately there are also documents about the safety analysis and cyber security measures. A lot of people that understand the software don’t understand the vehicle. A lot of people that understand the vehicle don’t understand software. So I spend time bridging the gap as a systems engineer.