As you may recall, in Part 1 of this mega-miniseries, your humble narrators (Max the Magnificent and Adam The Amazing) discussed some of the things you could do while at high school, college, and university to further your goal of landing a job in engineering.
Later, in Part 2, we pondered the creation of a resume (a.k.a. curriculum vitae, commonly referred to as a CV) and the joys of being interviewed. Now, in this final installment, we are going to cogitate and ruminate on how you can keep your job, grow in it, and evolve your career.
Let’s start by considering your first day on the job. Much like an interview, unless you’ve been explicitly informed otherwise, you really can’t go wrong by wearing a suit and tie. Even if your first position is with a small, casual startup company, they will appreciate the effort. Once again, remember the saying, “You only have one chance to make a first impression.”
Over the course of the first few weeks, in addition to wrapping your brain around your new duties, take some time to work out who’s who. In the case of a large company, start with your own department, and then ask around to work out how your department fits into the division and how the division fits into the company as a whole. What’s the corporate hierarchy? Who is in charge? Who reports to whom?
If you are lucky, the company you join will have a mentorship program in place. The idea here is that each new junior engineer is assigned an older, more experienced engineer whose task it is to guide them. If your company doesn’t have such a program, keep your eyes open and try to find someone who might be amenable to acting in a mentorship role.
I’ve told the following tale several times (it’s Max speaking here). My first position was as a member of a team designing CPUs for mainframe computers. I was assigned a mentor who we will call Dave Potts (because that was, and remains, his name). Dave would never answer even the simplest question directly; for example, Max: “Hey Dave, what time is it?” Dave: “Where is the sun in the sky, which way is the wind blowing, on what side of the tree does the moss grow, how...”
Dave’s policy was to lead you by asking a series of questions, thereby guiding you to discover the answers to life, the universe, and everything for yourself. In many ways this proved to be a superb learning experience (but you quickly learned not to question him as to the time).
Suffice it to say that the first project assigned to me was to design a pretty complex logical function in the form of a 128-bit barrel shifter and rotator that could execute in a single clock cycle, that could operate in multiple modes, and that could be implemented in a handful of gate-limited ASICs (this was circa 1980 and we’re talking about 2,000 equivalent logic gates per device). If Dave had presented me with the full requirements document up front, I would have ended up a gibbering wreck. Instead, he gave me a small portion of the task to work on. As I finished each step, Dave added a new requirement into the mix, guiding me step-by-step until I’d successfully completed the design and learned an incredible amount in the process without my brains leaking out of my ears. If only every junior engineer could be so lucky.
Depending on your personality, the first few days in a new job can be a little nerve-wracking. Don’t panic! Everyone has gone through this, including the people you are going to be working with. Try to project confidence without giving the impression of being cocky.
If you’ve recently graduated from university, you may be feeling somewhat self-important: “I am an engineer” (with “fear my wrath” in subtext). You may also feel superior to anyone who isn’t an engineer, including sales and marketing. Trust us on this, engineering, marketing, and sales are like a three-legged stool -- take any one of the legs away and the other two are useless (you don’t want to know what the guys and gals in the sales and marketing groups think about the folks in engineering).
Similarly, you aren’t going to get very far without the support of the office staff, the people who work in the warehouse, members of the janitorial department, and so forth. Remember that a cheerful smile and a kind word go a long way. The bottom line is, no matter how puffed-up you feel about yourself, nobody likes anyone who acts like a complete Richard or Richenda.
Speaking of which, one thing that really gets on non-engineers’ nerves is when they ask you a simple question and you try to show off and baffle them with techno-speak. Taking complex topics and making them understandable is a skill. Don’t try to convince people how clever you are -- this is something they will work out one way or the other for themselves pretty quickly -- it’s much better to explain things in such a way that your audience feels that they are the clever ones for understanding what you are saying.
The counterpart to the above is that you shouldn’t be afraid to ask questions. When I started my first position (it’s Max speaking again), every couple of weeks our department would hold a 1-hour lecture on something related to business or engineering. Invariably, the presenter would say something I didn’t understand, but I would be too embarrassed to put my hand up in case my peers and my superiors thought I was a fool. On every occasion, one of the more senior engineers, Joe Taylor, would raise his hand and pose the question I’d been pondering, at which point I would think, “Thank you Joe!” It was only much later that I realized Joe already knew the answers -- he was asking questions for the benefit of the junior engineers.
With regard to keeping your job and evolving into it, a good start is to always maintain an engineering logbook. By the end of your career you should have a collection of these little beauties on your shelf. Among other things, use this to record all the interesting things you learn (and where you read/saw them), the possibilities you consider (“Should I use circuit A or B”), the decisions you make (“I rejected circuit A because... and I opted for circuit B because...”), and the results from any experiments you make. With regard to the latter, never ever fudge the results to make them fit what you think they should be. There will always be underlying reasons for your getting results that differ from what you expect and discovering those causes will teach you a lot. It may be that you have to put any strange results on the “back burner,” but recording them now will allow you to return to them in the future when you have an “Ah Ha!” moment. As Isaac Asimov famously said, "The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' but 'That's funny...'"
Another point is to never stop learning. Don’t get blinkered into thinking only about your current narrow area of expertise. In my case (Max here), in addition to copious amounts of science fiction, I like to read books on subjects like computing, physics, chemistry, and biology, both for my own edification and also to give me a broader perspective (some recommendations would be, Nine Algorithms That Changed the Future, The Order of Time, The Disappearing Spoon, and Wetware: A Computer in Every Living Cell, respectively).
One thing I like to do (Max again, I’m afraid) is to always have one or two hobby projects on the go. I find that it’s a lot easier to learn something new if I start with a goal – something I want to do – and then work out how to achieve that goal. I find focusing on something that’s not work-related to be relaxing. In addition to giving me something to talk about and write about and show off to my engineering friends, I invariably end up learning a bunch of “stuff.” For example, one of my current hobby projects is a 12x12 array of ping pong balls, each containing a tricolor LED.
In addition to a bunch of other stuff, I ran across a clever way to implement a simple simulator that others can use to develop programs to run on my array. And, just a couple of days ago as I pen these words, someone introduced me to the concept of Core Wars, in which two little programs fight each other to survive in a virtual memory space. I’m now looking at implementing a Core Wars simulator on the Arduino, using my 12x12 array to display a representation of the ongoing battle.
If at all possible, get your company to send you to relevant conferences and exhibitions. While you are there, do your best to network like a champion. In addition to networking with people who work in similar fields to yourself, also try to meet people in other disciplines. You never know when you might need to ask someone a question about something, and people are much more amenable to sharing their valuable time helping someone they’ve met face-to-face.
We’ve said this before, and we’ll say it again – practice your writing and speaking skills. As you evolve in your role, you might want to think about starting a blog and submitting articles to print or online publications (get permission from your manager first), because this is a great way to “get your name out there.” Also, you might think about submitting proposals to present papers at these conferences. You might think you have nothing to say and that everyone already knows what you know, but this is rarely the case. The people who already know what you are talking about can go to another presentation, while the people who aren’t familiar with your area of expertise, but who want to learn more, will come to listen to you. This is another great way to “get your name out there,” both in the wider world and within your own company.
One of our friends, Jaime Villela, is passionate about persuading engineers to improve their communication skills. As part of this, Jaime has started posting a series of video interviews. At the time of this writing, three of these videos have been posted (with more on the way): Yours Truly (Clive Maxfield), Bill Schweber, and Adam Carlson. Bill is known throughout the industry for his analog expertise, while Adam manages to be a mechanical engineer who designs electronics and an aerospace engineer who designs submarines.
Be careful what you say on social media (nuff said).
As part of this project, we asked some friends if they had any thoughts they would care to share on this topic, a few examples of which are presented below:
Charles Pfeil: Respect. When starting a new job, the most important thing to do is to earn the respect of coworkers. This requires listening to, and understanding, their perspective and motivations.
Peter Smith CEng: Remember that other engineers are not your only audience. Communication skills are critical. How you communicate with senior staff will not be necessarily the same way you communicate with other engineers.
Antonio Giacomelli de Oliveira: If you are going to behave like an arrogant genius, make sure you are a genius!
Matthew Eshleman: Listen carefully. Work just a little harder than you think you can (but not too much; burn-out is real). Learn how to accept and process criticism. Be an engineer (seek out the deeper problem and the root cause of failures). Learn from others' mistakes. Show up on time. Do not lie. Be considerate when working in shared workspaces.
Member Dnj on EmbeddedRelated: I wrote my first program in 1967, so I think that I've seen a lot of things and met a lot of people. Here’s some advice to new "whiz kid" graduates at their first jobs:
Don't go into a new job thinking that you are the smartest person in the room. You probably aren't and this attitude will only generate resentment. Some of us were the best in our classes too and we've had to keep up with new technology without formal training.
If you are the smartest person in the room, then find a different company because this one isn't going to present enough challenges to keep you interested. Always find competition that is better than you so that you can learn and progress.