Resume Formating Template

Welcome to the first in a series of resume template blogs I’ll be writing.  Each one of these templates will be tailored toward a specific type of candidate—worried about a low GPA, nervous about your lack of work experience, concerned that a previous job was more relevant than your current one—I’ll be providing resume structures and tips to cover all of these issues.

Who is this format good for?

This resume format is ideal for the candidate who is not concerned with their GPA and who’s background is biased towards work and/or internship experience (as oppose to volunteer experience or strong classroom involvement such as class projects or undergraduate research).

Resume Format

This resume uses the format:

• Objective
• Education
  
• Experience
• Computer Skills / Additional Activities / Community Involvement / Etc.

Example Resume

Objective: Position with the Microsoft Technical Leadership Program utilizing my real-time software internship experience and leadership skills gained through extensive student government work

Education:
Bachelor of Science in Electrical Engineering
University of Washington, Seattle, WA
Expected Graduation Date: Jun 2009
Grade Point Average: 3.54

Work Experience:
Intel Simulations Division
Phoenix, AZ                                                Jun. 2008 – Sep. 2008
Real-Time Software Engineer

• Created software simulations that administered CPU performance tests on a GE X45 processor hardware test bed
• Used efficient coding techniques to create simulations that saved 20 minutes over the previous testing run time
• Created and maintained ISO-9450 compliant user documentation on 5 major simulation branches

Associated Students of the University of Washington
University of Washington, Seattle, WA            Jan. 2008-Jun. 2008
Elections Committee Chair

• Coordinated the successful completion of the 2008 student body elections while managing a committee of 4 people and a budget of $8,000
• Increased the number of candidates by over 40% and voter turnout by 4.3% (1615 total votes) over the 2007 totals

UW Leaders Program
University of Washington, Seattle, WA            Aug. 2007-Jun. 2008
Co-Director

• Administered a program containing 15 mentors and 25 undergraduate participants
• Oversaw weekly organization of leadership curriculum and guest speakers
• Raised $800 and organized a weekend retreat
• Increased program applicants by 100% and yearly funding from $500 to $2000

Computer Skills and Languages:
C++, Java, Python, FORTRAN, CORBA Interface Patterns, GE X45 Simulation Test Bed, Microsoft Access, Linux

5 Format tips

1. Font Type and Size – I suggest using a simple font type like Arial or Times New Roman in a type face of 11 or 12 points.  Try to avoiding using multiple types of fonts even for your name or address.  Multiple font types are often over utilized by students at the expense of readability and professional appearance.

2. Using Caps – Avoid using all cap headings.  Studies show that caps decrease readability.  Try reading an entire paragraph in all caps and you’ll quickly see this is true.  The exception is online application that offer a plain text box entry system for your resume.  Since these don’t allow font modifications such as bolding, all caps services as an acceptable alternative for your headings.

3. Bold, Italicized, Underlined – You can create a completely readable and clear resume using only bolded headings without other text effects.  Like font type, font effects are used far to often, almost always at the expense of clarity and flow.

4. Consistency – Check, double check, and triple check that your resume is consistent.  This means that all font is the same size, all spacing is the same, and dates, company names, and job positions appear in the same place in the same format throughout your resume.

5. Text Position – I think the text format that provides the easiest flow, and gives you the most bang for your buck in terms of available space on your resume, is left aligned headings with text appearing underneath (not to the right) of the heading.

Career Profile – Systems Engineer

Systems Engineering is a fairly new field that developed out of modern large-scale integration projects like those at Boeing and other system integrators.  System Engineers generally work across multiple teams on projects involving integration of two or more systems and often perform so-called trade studies to evaluate several possible solutions to a technical problem.

One piece of advice I would give those interested in this field is not to focus too intently on the term ‘Systems Engineer”.  For example, in my old position I was part of a software group and held the job title of Real Time Software Engineer.  Even so, I didn’t written a lick of code in 3 and a half years and my work was best described as Systems Engineering.  Instead, you should focus more on the type of work you want to do and then find job descriptions that meet that criteria.

So for example if you look online at the staffing system of a particular company you may see a lot of openings for “Systems Engineer”.  In addition to those positions try looking at more traditional engineering job titles as well and delving more into what your day-to-day activities would be as you move through the hiring process.  This will probably involve asking the employer at the interview about how much multi-disciplinary work you’ll have the opportunity to take part in.

Another thing to keep in mind is that Systems Engineers are often facilitators.  Because you work across multiple large and complex systems and teams of people, you can’t know everything about every system.  Therefore, a Systems Engineer often relies heavily on members of other teams and often acts as an intermediary to bring people from different teams together to find a solution.  Systems Engineers often end up specializing in a particular area (i.e. real-tme software) and over the course of a career eventually get to the point where they have medium depth knowledge of a wide range of technical areas.

The best Systems Engineers I know can balance not only the technical aspects of a problem but also the business aspects and the long term life-cycle impacts.  This is because the best technical solution doesn’t always imply the best solution from a cost, schedule, and risk point of view.

There are a few skills I notice good System Engineers having and they all revolve around the multi-disciplinary aspects of large-scale integration.  First, good System Engineers have a lot of experience with suppliers, subcontractors, and customers.  Knowing how to deal with a subcontractor when they are late developing a key item or negotiate with a customer when an important component doesn’t meet specifications is a very important skill.

Second, they know something about evaluation and testing and by association “selling off” a requirement to the customer.  When a contract is signed the goods or services provider signs a contract with the customer detailing the requirements of the good or service (these requirements are just one part of a larger contract structure).  At some point in time, these requirements must be tested to satisfy the customer that you are delivering what you promised (whether a requirement is well written is often defined by its testability).  Because System Engineers often work with requirements and requirements relate directly to testing, a good System Engineer is always evaluating how a particular technical solution will be tested.

Third, Systems Engineers know something about the life-cycle of a program.  When you deliver an aircraft to a customer, for example, that is not the end of the story.  The aircraft must be maintained and the parts, labor, and knowledge-base to repair an aircraft have to come from somewhere.  In addition, aircraft are often modified years after delivery as technology continues to improve.  Good System Engineers have the long term life of a product in mind as they search for the best technical solution.

Of course on top of these business oriented skills, a broad technical knowledge of a particular system is always required.  Usually this just comes with time and experience.  The best Systems Engineers I know probably have an average experience level of 15-25 years.  Of course, you have to start somewhere, so don’t feel overwhelmed by the amount of knowledge required to be successful.

As far as the type of tasks a Systems Engineer might work on, I can try to give a fictional example that demonstrates a typical situation and the issues you might deal with.  Say, for example, a supplier is suppose to deliver a hydraulic spring for use in a landing gear, however you recently discovered the spring isn’t rated to the appropriate tonnage and you get tasked with figuring out a solution.  (These sorts of disconnects happen all the time–why would you choose a supplier in the first place if their product doesn’t meet your requirements?  A variety of factors lead to these surprising sorts of problems.)  One answer might be to work with the supplier to modify the spring.  But because the spring has to be re-egineered there is a cost and schedule delay to completing the landing gear module.  Maybe the supplier offers instead to sell you a higher weight-rated spring that it already produces, but that is a slightly larger size and therefore doesn’t connect properly with the landing gear wheel housing.

So what do you do?  There are a variety of possibilities.  Perhaps you work with the current supplier and help provide resources to re-engineer the spring to meet specifications.  Perhaps there is an adapter you can buy that will help the more robust spring fit with the already fabricated wheel housing.  Perhaps your company is frustrated with the supplier’s schedule delays and you decide to risk trying to find a new supplier that already has a spring that meets your specifications.  Perhaps you conduct a study to show that, although the original spring doesn’t meet spec, it nonetheless provides a safe landing gear for the customer.  In that case you may have to rewrite the prime contract specification with the customer and try to sell them on the idea.

Other things you’ll need to consider when searching for a solution:  spares–what happens when the spring breaks, how will the spares be supplied, how easy is the spring to repair when it breaks, is the supplier in danger of going out of business soon (this happens to many small companies), if so who will supply the spring?  Testing: if you choose the more robust spring and adapter, how will you test it?  Requirements–do any requirements need to be rewritten or can they naturally be interpreted to be independent of the spring selection.  Other technical teams–if you choose the new spring does it add extra weight to the aircraft that might affect handling?  What about aerodynamic affects during take off and landing?  Will the sensor and/or software that monitors the spring’s hydraulic pressure need to be modified?

You can see that these sorts of situations get very complicated very fast and for that reason can be exciting, challenging, and frustrating all simultaneously.  And I think the complicated nature of these problems lend themselves well to people who have both a broad technical and business background.

If you like those kind of problems, you will probably like Systems Engineering.  The caveat of course is to make sure you can get on a good program with good people around you. I know some Systems Engineers who do the type of work I’ve mentioned above and others who sit at a desk working with requirements all day compiling comments other engineers made into a spreadsheet (obviously much less glamorous).  Again, I think this goes back to trying to find a job doing good work and worrying less about having the title of “Systems Engineer.”

Let me know which career profile you’d like to see next by leaving a comment below or e-mailing me at: collegegraduatejobs@gmail.com.