Engineer For A Government Defense Contractor
Job Title: Engineer
Type of Company: My company is a major US defense contractor, making large missile defense and satellite tracking radars, surface-to-air missiles, and air-to-air missiles.
Education: BS, Electrical Engineering, MIT MS, Electrical Engineering and Computer Science, MIT
Previous Experience: I have worked at the same company, a defense contractor, for 37 years.
Job Tasks: I work for a division of a large aerospace defense contractor whose primary customer is the US government, though the company is also allowed to sell some of our military defense equipment to America's allies. The division I work for designs and manufactures radar systems that are located at a handful of sites around the world and are powerful enough to detect moving objects such as satellites or missiles that are thousands of miles away. Such a complex and powerful system has many separate components: power supply, transmitter, receiver, antenna, computer, and signal processor. Each of these components, or subsystems, is designed by small teams of engineers whose efforts are coordinated by a "master plan" that dictates who does what and how the pieces fit together. The role that I play is that of System Engineer, one of a team of engineers that's responsible for ensuring that the System Design makes sense and that the various pieces of the radar will work together correctly.
I am called upon to use several capabilities. For some of the equipment, I use my knowledge of physics and math (both calculus and algebra) to determine how powerful a transmitter must be, how sensitive a receiver must be, and how large an antenna must be in order to detect an object in the sky thousands of miles away. Usually, there is no single "right" answer; instead, a system engineer has to use his judgment and experience to juggle several criteria: the speed at which a system can detect an object, the resources it would take to do so (how much fuel and electrical power it will need to consume), the space occupied by the radar, and last but not least, the amount that the customer is willing and able to spend to build such a device. Though I am occasionally required to solve equations using calculus, there are many software applications that aid engineers in such tasks. My most frequently used technical capabilities are simply high-school physics and algebra. Being comfortable in these two basic disciplines means that I can think about my engineering problems wherever I am with just pencil and paper, or in my head while driving to and from work.
At work, I am often called upon to decide which specific functions should be allocated to the piece(s) of the system that I am responsible for and then to calculate how much capability (power, sensitivity, etc.) the piece of equipment should have. These calculations are complex in themselves. But my labors never end there and I have to be able to communicate my conclusions -- my design ideas, my analysis, or whatever the outcome of my assignment is -- to others. Sometimes I summarize my ideas in text form, in a paper of the kind you'd encounter in a technical magazine. But often they're more graphical in nature: a block diagram, for example, (a simple line drawing in which pieces of equipment are rectangles connected by a few signals shown as lines connecting them), an X-Y graph of an expected sinusoidal signal at the input or output to the device, the expected orbit of a satellite traveling into the surveillance area of our radar, etc. There is usually some text accompanying these graphics, more like captions than full paragraphs. I am often required, later on, to collect several such diagrams that tell the story of my design and present them to my supervisor or to a group of other engineers so that we can all critique it. Ultimately, I can correct my design using feedback from the group. Occasionally, I present some aspect of my design to representatives of the customer.
Finally, I bring another capability to bear in my job. When the various parts of the system are built and connected, the signals that travel between each device must be checked to verify that each is working correctly and the radar system as a whole is producing the information needed by the customer. Often, I use skills that I learned in the lab at college, such as using test equipment, meters, oscilloscopes, etc. Often, I using software applications which I must "program" to analyze the computerized output from a radar to determine whether it is performing as well as expected or perhaps requires minor "touch-ups" in its design to be more effective.
Best and Worst Parts of the Job: One of the best parts of an engineering job is when you are part of a new project and you are starting with a "clean slate." Your challenge and the source of your satisfaction is organizing your knowledge and ideas to solve the problems that make your project a step forward. You may also brainstorm your approaches with other engineers; it's like magic what creative schemes come out of brainstorming sessions.
One of the worst parts of the job for me is that your supervisor always wants to know when you will be finished or that you will be finished by a particular deadline. Problems do not always want to be solved on a schedule!
Job Tips: Despite there being many software applications that reduce the burden of calculation and having to remember equations, learn math and physics carefully and thoroughly. This knowledge affects how quickly solutions pop into your head and whether or not they are feasible. It saves time not always having to turn on the computer to test each and every idea.
Learn to communicate! High-school English class has been important in my career because I am able to write and speak well enough to be understood clearly.
Don't just focus on technical capability. Engineers should be citizens of the world of politics, sports, economics. Your engineering solutions affect all of these and you will be a better provider of technology if you know its effects.