Resume Review

Resume Review

Use this skill for engineering resume critique, rewriting, and formatting. Base guidance on the r/EngineeringResumes wiki principles: make the resume easy to skim, ATS-parsable, technically specific, concise, and biased toward the most relevant/impressive details.

Review Sequence

1. Identify the candidate context: student/new grad, no technical work experience, experienced engineer, senior/staff, or career changer.
2. Check layout and accessibility.
3. Check section order and section names.
4. Check contact information.
5. Rewrite work/project bullets for technical action, context, and results.
6. Check education, skills, projects, and portfolio links.
7. Remove weak, biased, stale, or unnecessary content.
8. Proofread grammar, punctuation, spelling, dates, capitalization, and ATS readability.

Resume Effectiveness Principles

Treat the resume as a 30-second elevator pitch on paper:

• Make it succinct, easy to follow, and informative.
• Include relevant technical details that distinguish the candidate from similar applicants.
• Provide context and relevant keywords so recruiters, hiring managers, and interviewers understand the work.
• Avoid unnecessary information that does not strengthen candidacy.
• Put the most critical and pertinent details near the top and left of the resume.
• Reduce distractions so readers can quickly locate important details.
• Prevent wall-of-text sections by using concise bullets and enough white space.
• If the resume cannot fit on 1 page, remove content that is less relevant to the target role, even if it is technical; move secondary material to a portfolio instead.

Layout And Formatting

Apply these rules:

• Use a single-column layout.
• Avoid icons, images, graphics, and decorative elements.
• Do not indent sections or bullet points beyond the natural bullet indentation.
• Use bullet points, not paragraphs.
• Use a modern readable font such as Calibri, Bitstream Charter, Arial, Lato, or Helvetica.
• Use black text, not gray text, and avoid thin fonts.
• Verify the resume has sufficient contrast on a white background and prints clearly in grayscale.
• Use at least 10.5 font size.
• Do not justify text.
• Keep enough white space; do not cram content.
• Use at least 0.4 inch margins.
• Use at least 1.07 line spacing.
• Use clear section separation.
• Keep sufficient and consistent white space between sections, subsections, jobs, and projects.
• Avoid excessive italicization, bolding, and ALL CAPS.
• If bold, italics, or all caps are used, use them sparingly and independently.
• Do not italicize text when avoidable because it can decrease readability.
• Do not bold keywords inside bullet points because it is distracting.
• Keep to 1 page unless the candidate has roughly 10+ years of experience.
• Use the rough rule of thumb: 1 page per decade of experience.
• For senior/staff candidates, try not to exceed 2 pages.
• Move critical and relevant details toward the top and left of the page.
• Right-align dates to the right margin.
• Ensure bullet text does not extend farther right than dates.
• Avoid wrapped final lines containing only 1-4 words.
• Do not allow automatic word hyphenation across lines.

ATS And Templates

The resume should be easy for recruiters, hiring managers, interviewers, and Applicant Tracking Systems to read:

• Prefer simple, ATS-friendly layouts over ornate templates.
• Recommended template styles are the r/EngineeringResumes Google Docs and LaTeX templates.
• Use a single-column template similar to the r/EngineeringResumes LaTeX example.
• Avoid formatting that depends on graphics, icons, tables, text boxes, columns, or hidden content.
• Keep links and contact information as plain text so parsing remains reliable.

Dates

Use consistent date formatting:

• Use Present, not Current, Now, or Ongoing.
• If months are included, use months consistently and do not mix seasons or semesters.
• Do not include specific days.
• Do not abbreviate years.
• Do not use numeric month/year formats.
• If abbreviating months, use Jan, Feb, Mar, Apr, May, June, July, Aug, Sept, Oct, Nov, Dec.
• Do not put periods after month abbreviations.
• Use en dashes for date ranges with spaces around the dash, such as Mar 2012 – Mar 2022.
• Do not use hyphens or to for date ranges.

Section Order

Use the candidate context to choose order:

• Experienced after graduation: Work Experience, Skills, Education; or Skills, Work Experience, Education.
• Student/new grad with some work experience: Education, Work Experience, Skills; or Education, Work Experience, Projects, Skills.
• No technical work experience: Education, Projects, Work Experience, Skills.
• No work experience: Education, Projects, Volunteer Experience/Extracurriculars, Skills.

Do not include:

• A summary/profile unless senior/staff, changing careers, or addressing a work gap/return.
• A references section.

Contact Information

Keep contact details minimal and plain:

• If relevant, list security clearance near the name, such as Top Secret / SCI eligible with CI Polygraph.
• If work authorization may be unclear, consider listing citizenship or visa/work status near the name, such as US Citizen, US Permanent Resident, Canadian Citizen, or Italian Citizen.
• Do not include physical address or ZIP code.
• Do not include city/state unless the job is in that specific city.
• Treat non-local location and non-local area codes as possible sources of implicit bias.
• LinkedIn is usually unnecessary.
• Phone number is usually unnecessary.
• If listing a phone number, do not prefix it with Phone, Cell, or Mobile.
• In the US/Canada, omit +1.
• List only 1 email address.
• Prefer modern email providers such as Gmail or Outlook.
• Avoid AOL, Hotmail, and Yahoo email addresses because they may create implicit bias.
• Do not use college email after graduation unless the school is highly prestigious.
• Do not include an empty GitHub profile.
• Write email, GitHub, and portfolio URLs in plain text.
• Do not mask links behind labels.
• Do not include https://www. in URLs.
• Do not prefix links with Email, GitHub, or Portfolio.
• Do not underline, italicize, or color contact links.

Work Experience

Use Work Experience or Experience as the section name.

Apply these rules:

• Include only paid work experience and research experience.
• Clearly label internships as internships and contract roles as contract roles.
• Order positions and bullets by relevance to the target job or impressiveness.
• Tailor content to the job description.
• Add context so the reader understands what was built, solved, improved, or validated.
• Differentiate accomplishments from job duties.
• Include tangible metrics and technical victories when available.
• Focus on engineering skills behind tools, not just the tools.
• For new grads, emphasize mastery of fundamental engineering skills before management or leadership claims.
• In mechanical or analysis work, mention hand-calculation sanity checks when truthful; this shows engineering judgement beyond pressing run in FEA/CFD tools.

Bullet Points

Each bullet should highlight technical work, technical challenges, and impact.

Rules:

• Use bullets, not paragraphs.
• Keep bullets to 1 sentence and usually 1-2 lines.
• Put the most relevant or impressive bullets first.
• Do not use personal pronouns such as I, we, us, my, our, or their.
• Do not end bullets with periods.
• Avoid excessive sub-bullets.
• Avoid apostrophes, ampersands, and slashes where possible.
• Avoid excessive adjectives and adverbs.
• Avoid empty praise words such as excellent, innovative, expert, revolutionary, disruptive, creatively, diligently, meticulously, strategically, successfully, independently, innovatively, excellently, and expertly.
• Use digits instead of spelling out numbers.
• Begin each bullet with a strong past-tense action verb.
• Follow STAR, XYZ, or CAR.
• Move quantified results toward the start of the bullet when available.
• Preserve truthful scope and do not invent metrics.
• Use tools such as QuillBot and LanguageTool to paraphrase and shorten bullets when needed.

Preferred action verbs:

• analyzed
• architected
• automated
• built
• created
• decreased
• designed
• developed
• implemented
• improved
• optimized
• published
• reduced
• refactored

Note that Led is the past tense of lead.

Avoid weak or awkward verbs:

• aided
• assisted
• coded
• collaborated
• communicated
• executed
• exposed to
• gained experience
• helped
• participated
• programmed
• ran
• used
• utilized
• worked on
• amplified
• conceptualized
• crafted
• elevated
• employed
• engaged
• engineered
• enhanced
• enhance
• ensured
• fostered
• headed
• honed
• innovated
• mastered
• orchestrated
• perfected
• pioneered
• revolutionized
• spearheaded
• transformed
• leveraged
• leverage

Use STAR, XYZ, or CAR:

• STAR: situation, task, action, result.
• XYZ: accomplished X as measured by Y, by doing Z.
• CAR: challenge, action, result.

Bullet Discovery Questions

Use these questions to extract stronger bullet content:

• What did the candidate do?
• Did they solve a problem?
• Did they work on a team or independently?
• How many people were on the team?
• How did they do it?
• Why did they do it that way?
• What tools, standards, resources, or methods helped?
• Did they test or validate the design?
• How did testing affect the final design?
• Was the project delivered on time or under budget?
• Did the solution work as intended?
• What went wrong, and what was learned?
• What goals existed at project start?
• Were those goals met or exceeded?
• Did the outcome exceed the original goal in speed, scope, quality, budget, precision, reliability, or usability?

If a metric is missing, ask a targeted question or use a placeholder such as [metric] only when the user explicitly asks for draft language.

Integration And Sensitive Content

Prefer integration-focused bullets over parts lists:

• Explain how components, software, hardware, tools, or processes worked together to accomplish the goal.
• Do not merely list components or technologies.
• Show technical ability by explaining the interface, precision, validation, or design reasoning.

For sensitive work:

• Discuss the technologies and engineering contribution without revealing protected details.
• Replace forbidden program, product, or customer specifics with broader technical descriptions.
• Keep enough technical context to avoid vague "did stuff" bullets.
• Do not disclose proprietary processes, exact designs, sensitive customers, or classified details.

Education

Apply these rules:

• Do not include coursework unless highly specialized or unusually relevant.
• Do not include high school.
• Do not include schools where no degree was received.
• Do not include education start dates.
• Use only graduation date or expected graduation date.
• For current students, use Expected May 2025 style.
• For graduates, use May 2021 or 2021.
• Order education reverse chronologically.
• List master's degrees above bachelor's degrees.
• Generally include GPA only if above 3.75.
• Use 2 decimal places for GPA.
• Remove GPA after first full-time job unless it remains very impressive.
• Use Bachelor's of Science and Master's of Science.
• Do not include school location if it is in the school name or commonly known.
• Do not include awards or scholarships unless extremely impressive.
• Include D1 or competitive sports.

Skills

Use Skills as the section name.

Purpose:

• Highlight technical skills relevant to the job in a few words.
• Match the job description where truthful.
• Balance breadth with credibility.
• Include adjacent technical skills when they strengthen the application, such as listing C++ for a Java role if the candidate can support it.
• Do not list every buzzword ever touched.

Include:

• Languages used thoroughly enough to interview in.
• Technologies, frameworks, tools, and programs used previously.
• Skills that also appear in bullets, and bullets that support skills listed.

Do not include:

• Soft skills such as teamwork or leadership.
• Skills assumed for engineering work, such as typing, Microsoft Word, or IDEs.
• Code repository websites as skills; use Git or SVN, not GitHub, Bitbucket, or GitLab.
• Operating systems.
• IDEs or word editors such as VS Code, LaTeX, or vim.
• Descriptors such as expert in or professional in.
• Random hobbies.
• If hobbies or unrelated passions are included, put them outside Skills and only when there is no stronger resume content.

Format:

• Keep to 3 lines or less.
• Use a single-column format.
• Order skills from most important to least important.
• Remove weak skills at the end when they dilute the section.
• Group skills into relevant categories such as Software, Mechanical Design, Simulation and Analysis, Manufacturing, Lab Equipment, Languages, Technologies, or Design Tools.
• Separate skills with properly punctuated commas.
• Do not use hyphens, dashes, pipes, or slashes as separators.
• Capitalize proper skill names correctly.
• Separate functionally different skills, such as C, C++, not C/C++.
• Do not bold random words.
• Do not use multiple columns.

For inexperienced candidates, use judgement when listing skills they are not very comfortable with. A short list of well-supported skills can look stronger than 10+ lightly touched skills.

Projects

Use Projects as the section name.

Apply these rules:

• Use for personal projects, student design teams, and extracurricular/hobby projects.
• Do not use for work projects.
• Do not include the word project in project titles.
• Capitalize project titles correctly.
• For personal projects, roles, positions, locations, and dates are usually unnecessary.
• Prefer a portfolio or GitHub repo link when it adds value.
• Do not label projects as Personal Project, Academic Project, or Group Project.
• Use bullet points, not paragraphs.
• Order projects and bullets by target-role relevance or impressiveness.
• Prefer real, maintained projects that solve a problem and have users, even if the user is the candidate.
• Avoid trivial tutorial projects and mandatory school projects when stronger projects exist.
• Strong project sources can include student clubs and competitive teams such as SAE, AIAA, rocketry teams, FRC, or FTC.

Portfolios And GitHub

Apply these rules:

• Include GitHub or portfolio links only if they are current and valuable.
• Omit stale portfolios.
• Omit GitHub profiles if pinned repositories lack useful READMEs.
• Publish projects with strong READMEs.
• READMEs should include summary, screenshots, run instructions, and test instructions.
• Include runnable automated tests when possible.
• Automated tests can include unit tests or end-to-end tests.
• Take inspiration from projects with excellent READMEs.
• Portfolio guidance can be useful, but do not include portfolio links unless their contents add meaningful value.
• Do not include full URLs with https://www..

Bias And Personal Details

Remove personal details that can create negative bias:

• age
• gender
• children
• nationality, except when explicitly clarifying work authorization
• ethnicity
• marriage status
• religion
• political views

Also remove non-local location details unless directly relevant to the target role.

Senior Engineers And Above

For candidates with 10+ years of experience:

• Consider a brief summary under 2 sentences.
• Keep separate resumes for management and individual contributor roles.
• Try not to exceed 2 pages.
• Include soft achievements only when tied to business results.
• Show influence as well as direct impact.
• Compress earlier work experience.
• Move education to the bottom.

Career Changers

For career changers:

• Include a brief 2-sentence summary explaining the career change and motivation.
• Link to working projects and source code.
• Be concise when summarizing prior career experience.
• Try to keep the resume to 1 page.

Grammar, Punctuation, And Spelling

Apply these proofing rules:

• Spell out obscure abbreviations on first use.
• Do not capitalize every word of an expanded abbreviation unless it is a proper noun.
• Run grammar and spelling checks, not just spell checks.
• Check punctuation and capitalization.
• Capitalize only proper nouns.
• Use tools such as Grammarly, Hemingway Editor, LanguageTool, and QuillBot when helpful.
• Ask for another proofread when possible.
• Ask friends or family to proofread when possible because fresh eyes catch mistakes.

Output Style For Reviews

When giving feedback:

1. Start with the highest-impact issues.
2. Cite the section or bullet being discussed.
3. Explain why it hurts skimmability, technical signal, relevance, ATS parsing, or credibility.
4. Provide a concrete rewrite or action.
5. Keep the review focused on changes that improve candidacy.