Some tips to fresh-out engineers looking for a job

I’m only in my seventh year out of college, which is not a lot, but it is enough to have seen plenty of résumés. I’ve just been reviewing some new ones and remembered that I’d planned this post.

Here are my tips on making a good résumé. These are my tips, an engineer, not a hiring specialist, so follow at your own will. Also notice that these may not be relevant to fresh-out accountants or dentists, these are things that as an engineer looking for engineers for a technical position either bother me, make me go crazy or simply I would recommend…or simply as a person who appreciates good writing skills, a little bit of both…check ‘em out:

• NO CAPS LOCK. PLEASE, OH PLEASE, NO CAPS LOCK: no explanation needed, just don’t do it, nobody likes it. If you don’t understand this point, may I direct you to one of my favorite web comics, The Oatmeal: minor differences.
• If you’re doing a résumé in a language different than your native language, make sure you research the proper way to express terminology that you’re not sure about. Tip: any word that sounds very similar in both languages is not necessarily the most correct translation. For example, “compromise” in English and “compromiso” in Spanish mean different things. Note: I researched how to write “résumé” for this post.

• No need to put ALL of your personal info there. Your height and weight are not needed. I personally don’t even think your address is needed. A phone and email is more than enough. If you have a unisex name, probably add whether your male or female, most online application systems will have that option already, so it’s also not entirely essential. Extra points: if you have a “peculiar” email like g33k_10RD_666@hotmail.com, use a different email, if you don’t have another one open an account in gmail with your actual name.
• You are applying for an engineering job, your engineering credentials are what’s relevant, unless human resources needs to know for some bureaucratic reason, don’t include you elementary school, junior high, high school or your chef certifications, nobody cares, and if they care they’ll ask in the interview. Include bachelor’s degrees and above. If your high school was a technical high school, then include it.
• Similar to the previous point, I repeat: you are applying for an ENGINEERING job, nobody cares if you are good at MS Office 97, 2003 and 2007. I wouldn’t even put Word in there, it’s a given that you know about basic software. You’ve recently finished college, you wouldn’t have been able to do that if you didn’t know how to use Word. If you have an advanced Excel-something certification, for example, if you can do pivot tables and program VB macros like nobody’s business, then, by all means, put it in your résumé, if you know how to graph something and do some calculations, then DO NOT mention it, everybody assumes you know it. Same goes for HTML, nobody programs in HTML anymore. You can do web applications in javascript? Good, write it down. You know how to add meta-tags in HTML, don’t write it, nobody cares, because if you’re applying for a web-something job, you SHOULD know it and if you’re not, then it doesn’t matter.
• Don’t give specialized tools or knowledge more importance than they actually have. For example: multimeters and oscilloscopes are not particularly important because you should know them (if you’re an EE, at least), logic analyzers, RF signal generators, specialized sniffers, those are things that are actually important to highlight for a fresh-out.
• Also don’t give school projects more importance than they have. If it’s your thesis project or something that actually had some complexity outside the scope of a single subject, consider putting it there. Only include school projects if you don’t have any additional experience, ideally you should have done an extra effort in college and you would have internships, expos, competitions, etc. under your belt, those experiences are more important because they speak of more work and a willingness to go beyond.
• Review your grammar and spelling. If you’re bad at it (cause you’re an engineer and you probably are) ask a friend to review it for you. Pay them with beer.
• Make it easy on the eyes. I don’t mean you need to do some fancy graphical design, but make it orderly, make it easy to read. Have sections in an order that makes sense. Ask someone to take a look at it and tell you if they like it. Look for pre-designed formats on the internet and base your résumé on that. There are many things to say here, but mostly, use a decent format, get opinions and most important of all: DO NOT USE COMIC SANS.
• Put your sections in order of importance. Usually hiring people care more about your work experience than your studies, so put that first. Within special abilities, focus more on the important ones for the job and less on your football tournaments.
• Be truthful, do not make up that you have java experience because you programmed a “hello world” in java.

That’s it, hope my recommendations help you, or at least made you laugh.

Creativity

Yesterday I had an interesting conversation about working in embedded systems with someone who’s not an engineer, turns out I’ll speak to her college sociology class about creativity, how to loose it and how to keep it.

Engineering is a creative career, don’t let anybody tell you otherwise. I could agree that there are engineering variations that are less creative than others. For example, to me quality engineers are probably allowed less creativity as their work is to enforce standards. But I say only probably because I can think of several ways they can be creative, like in designing their testing procedures.

My problem with creativity in engineering is with all the corporate red tape needed to exert creativity. When you work for a company (like I do), many times you have to sign a document that basically gives the company ownership of any ideas you have. I’m not a lawyer so I don’t really understand how far that document goes. For example, I don’t think they own my ideas for better omelets, but they do my ideas for software optimization. I understand the idea behind this type of contract. I’m working under their roof with their equipment and their resources. But the brain that came up with the idea is mine, so, who’s idea is it? I don’t have the answer. What I do think is that companies should have better ways of sharing intellectual property with employees. If IP is so important, than there should be some sort of shared ownership.

Again, I’m not a lawyer and I don’t understand the legal implications of these ideas, but from a personal stand point, this would be very motivational, it would actually mean to “own” my work, which, in practical terms, means that I’m far more committed to the results of the company.

 

As engineers we are motivated by different things. It is common for engineers to pass on a better salary offers if it means a more boring job. Not that engineers don’t want to make money, it’s simply a priority second to the challenge and the thrill of solving a problem or coming up with something new. I think companies that are good at challenging their engineers and making them own their innovations will always succeed in having the best talent. It also helps to make innovating easy as possible. I would love to see more companies out there allow their people some time to just be creative with their work rather than simply making the deadlines.

Article notice: Improving the transient immunity of your microcontroller-based embedded design

A couple of colleagues from Freescale Semiconductor published an article on designing MCU systems for improved transient and EMC performance. I recently found out it’s in EETimes, where I can share it, as opposed to an internal power point.

So here it is, some really great tips on hardware design for improved EMC, EMI, transients, etc.:
Improving the transient immunity of your microcontroller-based embedded design

Tiny animals live in my desk (and they feed on copper)

There are some tiny animals living in my desk, they live on a PCB blank and they feed on copper. They have been slowly etching away a circuit whilst eating…I suspect the panda is their leader and the duck is his bodyguard.

 

I just hope they don’t learn to program and/or hack into my computer while I’m away.

 

More info as this story develops…

Motor control article in DigiKey’s TechZone

My paper on BLDC motor control has been published on Digikey’s magazine Techzone!

Check it out: Using Kinetis BLDC Motor Control ApplicationsPreview

 

 

 

 

 

 

Web stuff that’s actually good

While project awesome robot is still on-going, I want to let you know about a site I recently ran into (because they started following me on twitter, and so should you). It’s called EE Web and it’s awesome awesomeness. It’s got some really great resources (click on the Tools tab and you’ll see), great articles and (best for last) a great comic depicting some EE’s on the job. Not IT people, not fake geeks, this comic (Return to Zero) I can actually relate to, check it out!

This is the kind of stuff I want to see on the web even more, a fresh interface, good information that’s not cluttered and stuff I, as an EE and embedded developer can relate to, kudos to EE Web!

Check ‘em out at:

http://www.eeweb.com/

And follow them on Twitter: @EE_Web

You should build a robot, and so should I

I’ve been thinking about this for a while. I have never built a robot. I’m an EE, I know about motor control, I have made or controlled parts that robots use, but I have never in my life built a robot. I am about to turn 30 and I have not built a robot, and robots are awesome, hence, I am not awesome, but I am sort of awesome, so I must build a robot to assert my awesomeness.

My commitment to you, my readers, is that I will build a robot, I will post pictures, and it will be awesome.

Now, off to find robot parts!

 

BTW, here’s a robot that’s already been built for you, really awesome Freescale awesomeness:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FSLBOT

Touchy video!

I’m back after a few months of intense work. I have some fun things in the oven. While some new posts are baking, I’d like to leave with a video I made for Freescale touch sensing technology during the 2011 Freescale Technology Forum in San Antonio last June. Enjoy!

Going FTF way

It’s that time of the year again. FTF 2011 is upon us and I’m happy to say I’m attending once again.

Some of the fun I’ll be having: touch sensing trainings, appliance, power management and touch sensing demos, tweeting, talking to customers, meeting random engineers, talking to friends I haven’t seen in a while, trying to remember names of people I’ve only met once.

It’s going to be awesome! I hope you’re attending as well, if you are, look for me on twitter: @EmbeddedStories

If you aren’t, follow these people so you’ll get the inside scoop on stuff going on at FTF:

@Freescale, @squadMCU, @nixxil, @bcbg17girl @Engineer_in_MKT, @HealthDevices, @nericciani, @element14, @TouchSensing

A big follow should also go to Joe Grand, who’ll be there hosting the MakeIt challenge: @joegrand

If you don’t know what FTF is, go to:

www.freescale.com/ftf

See you there (in real or virtual form )

Lessons in motor control

When you do a new motor control board that you’re calibrating for the first time, buy a whole bunch of extra FETs. You’re going to burn at least a set and then you’ll end up “borrowing” them from other boards, true story.

I (heart) ESC (and pictures!)

I traveled to San Jose, California last week for the Silicon Valley Embedded Systems Conference. It was an awesome experience as I had never been to an ESC before.

I don’t really have too much to talk about the keynote speeches, I wish I could, but as a speaker and exhibitor you actually have too much work to do, and when I didn’t have work I was at the Freescale booth showing people demos and talking to other engineers.

This part of the conference was actually really great, I got to meet so many people, from young engineers (one even asked for career advice), which honored me a lot, to seasoned experts who had some really great insights (notice how I say “seasoned experts” to not say “old engineers”, I am so politically correct…wait…)

I have so much to talk about ESC, but I have some pictures to share, so I’ll let the pictures talk.

First some pictures from the theater sessions. The Freescale booth basically had a small theater and we took turns speaking about several new products and technologies.

Eric Gregory showing his awesome creation, the FSLBOT

Clark Jarvis talks about graphics libraries using MQX RTOS

Paulo Knirsch and Phil Drake talk about the new Coldfire+ family (marketing and engineering happily working together, by the way)

From the booth:

Cuau Medina (aka @HealthDevices) spent several hours driving the VGo robot around ESC (http://www.vgocom.com/) He even met some girls (but didn't get their number cause he's a gentleman)

The watt saver (pat. pending) reference design. New technology designed to eliminate vampire power from idling chargers and other permanently plugged-in devices.

Extras:

Stealth picture I took of the attendees at the "Battery Powered, High-Accuracy and Reliable Capacitive Touch Sensing" class just before starting my hands-on portion

"You break you buy, I break I cry." Ok, so this picture wasn't taken at ESC but rather a couple of days later in China Town in San Francisco, but I thought I'd share the laughs

So that’s it for pictures, I usually don’t take too many pictures because I want to appear all cool instead of all touristy (at least that’s what I think I look like, not that anybody looks like a tourist at a conference…unless it’s the tourism conference, then it just gets weird…)

More playing around with RTOS, to task or not to task

So back in November 2009 I posted an article about my starting to play around with RTOS to grow in my technical knowledge. I must confess something: I haven’t really played with MQX or others as much as I would have liked…at least not during 2010. But then something happened: Freescale’s Kinetis family of ARM microcontrollers was launched and now my worked has forced me (in a good way) to work with the MQX RTOS quite a lot more. It’s been great fun.

In my self-training of MQX I’ve run into basically two ways of doing things. One way is to subdivide all functions into tasks, using all sorts of RTOS goodies like semaphores, priorities and mutexes (is that the right plural? How about mutexii?). This way, as far as I understand RTOS, is the right way to do it, it’s elegant.

On the other hand, I’ve seen code were the author basically creates two or three tasks and then proceeds to manually do the application control manually i.e.: switch-case statements with binary flags and stuff. Almost as doing a bare metal application where the RTOS is only there for the drivers. Correct me if I’m wrong, but, doesn’t that beat the whole purpose of using an RTOS?

My intent is not to criticize whoever writes code that way, I’m mostly interested in considering the caveats of doing the code one or the other way. For example, I can imagine a situation in which going crazy with OS tasks could result in an overly complex system, so probably a balance between tasks and manual control makes most sense. On the other hand, an overly complex system would probably be more the result of improper RTOS usage rather than an RTOS having a chaotic nature (which makes sense, now that I’ve written and read that).

So what’s your take on RTOS software? Do you think all RTOS resources should be exploited as much as possible?

Is learning a new language sexy?

Embedded software engineers only need to know one programming language to get through life: C. Most embedded software projects are written in C. So that leaves most other languages out of use (I insist, for embedded programmers). I always wonder if I need to start learning a new language, and if so, which one. With so many things to keep learning about, I usually barely have time to read up on the latest developments in the technologies I work with, so learning a new language has been constantly left “for later”.

 

C++ seems to be a pretty obvious choice as a next programming language, as far as I know, it’s the second most used language in embedded systems. There are also some less obvious choices out there like Ada or B# (yes, you read correctly).

 

The main issue with other programming languages is a combination of adoption and the benefits of C. It is well-known that C has very little overhead. Having compiler companies adopted C as the de-facto standard for embedded systems, optimization technology has completely focused on C for at least 2 decades, leaving any other language far behind. Ok, so C++ is nearby, it’s still C (I am now hiding my head under the desk waiting for some rocks to be thrown my way).

 

I’ve also played around with languages that aren’t at all related to embedded systems (at least that I know of). I’ve studied some Python, for the purpose of creating automated test GUIs and just for the fun of it, I like it a lot. That’s another practical aspect of other languages, they may be used as support for our embedded projects.

 

What is your opinion? Will C reign in embedded systems forever? Towards which language will embedded systems turn in the future? Should I start learning a new language? Which one?

 

A note, I should thank  Coding Horror (@codinghorror in twitter) for posting The Pragmatic Programmer Quick Reference Guide, it got me thinking about this and other things I’ll post about in the future.

One of my favorite things in electronics

I’ve been underposting, sorry about that…hope you faithful readers understand where my blog is coming from: an embedded engineer, meaning: overworked. I’m not complaining, I like it that way, as long as it’s not ridiculously excesive.

 

For your reference, these are my definitions for engineers:

 

• Half-time: 4-8 hours a day
• Underworked: 6-8 hours a day
• Normal: 8 hours a day
• Tolerably overworked: 10 hours a day
• Extremely overworked: >10 hours a day
• Ridiculously overworked: gets home and says “wow, I forgot about this bed!”

 

So I’m between normal and tolerably overworked right now, which is fine, but my blogging time takes a hit.

 

Anyway, I’m at the lab working and I saw this thing that I like so much, that I work with everyday and I though I’d share it with you:

 

Big, beautiful terminal block connector

Yes, that’s it, a terminal block connector. Did you think it would be an oscilloscope? Signal analyzer? Debugger? My computer?

 

Nope, I love terminal connectors, they’re big, robust, easy to work with (I’ve got the gorilla hands), simple, practical…oh wait, they’re everything embedded software should be…and isn’t. My philosophy regarding building great software is that, build it like a terminal block. Ok, probably not the “big” part, but, if it has to be big, then all the more reason to make it robust, easy to use, simple, etc.

 

I didn’t have one nearby, but I love the two-part terminal blocks even more, the ones that you insert the cables into one end and then plug the whole thing into the board-soldered end. Those are AMAZING, I wanna marry them!

 

(Breathing in and out)

 

Ok, not so much, but they’re cool. Again, a really nice metaphor for great software, software that you can easily split apart and then integrate back. That you can seamlessly take away one layer and integrate another layer without big changes to the system…that’s the dream.

 

That’s it for my post today. Leave a comment, what’s your favorite thing in work?

The lab or the cubicle?

Imagine this: you’re done with your lab work. You can go back to your cubicle/office/desk where co-workers can easily find you and distract (albeit, you can also probably have fun conversations) or you can stay in the quiet, isolated happiness of the lab and be super productive. What do you do?

I usually go for my cubicle. I have to admit, I am usually less productive in my cubicle. Mexicans tend to be noisy, nosy and easily distracted, meaning that being in my cubicle there’s a 99.9% chance that someone will interrupt me. On the other hand, just one of those distractions may end up being about something I didn’t know, a new idea, the birth of a project or a reminder of some task I forgot to do. My office works that way, our collaboration is high, mainly due to everyone being able to bother everyone else. It’s a wonderful cooking pot, an engineering stew, and I love it.

 

Except for the insanely brilliant and solitary minds, ideas are born this way. This is why I (mostly) always choose my cubicle. This has it’s downside, I’m so easily distracted that I usually have to make up for lost time after hours. It’s not a complaint, it’s just a fact, I prefer my work to happen this way. Why would I like to be an engineer in a stale environment without any idea exchange?

 

Of course I do sometimes need to be productive, after ideas are born someone has to turn them into a reality, that’s when I’ll take my headphones and isolate myself, either in my cubicle or in the lab. I also like that, to be so absorbed by something that it’s suddenly 7 in the evening and I didn’t even notice. I just can’t do it all the time, I’d probably wear my brain out.

 

My view is that collaboration is always better than brilliant over-productive single minds. An interesting mix of these two happens at Facebook. We’ve all seen it, either by seeing The Social Network movie (I do recommend it, by the way, great acting) or from the pictures in articles, the Facebook offices don’t even have cubicles, just desks, everyone can see everyone else. Even Mark Zuckerberg (Facebook creator) can be seen in one of those desks, coding away, instead of in some fancy corner office. But also, as can be seen at the beginning of the movie, Mark Zuckerberg is also a brilliant lonely coder. So it’s an interesting mixture, they hire brilliant minds but they enforce an environment in which collaboration is key, they even use modern practices like Xtreme Programming, where programmers pair up and work together (I’ve written some stuff on pair programming here).

 

So what are you? The isolated type or the collaborative type?