I’ve been a software quality assurance engineer for more than thirty years and have done my share of job hunting. Also, I’ve been a hiring manager a number of times throughout my career, so I’ve screened a lot of technical resumes as well. I’ve developed some opinions about how resumes should be formatted to facilitate the way I do resume screening as well as some other opinions about resumes. Recently, quite a few of my friends and former coworkers have been job hunting, and I’ve helped a number of them with their resumes, so I thought it was time to write up my opinions.

I know that there is a ton of advice out there about resumes, much of it conflicting. My expectation in writing all this up is just to offer my perspective. I’ve gotten good feedback from people who I’ve helped with their resumes, but I do not claim that my advice is best practices. I As you read this, take the things that make sense to you, discard anything else.

My resume screening process

When I’ve been a hiring manager, here’s how the resume screening stage of hiring has always worked (in cases where I didn’t work with an HR partner and had to do all the resume screening myself, the process starts with my scanning for keywords, at step #3 basically):

1. Meet with my HR partner to discuss what I’m looking for generally and to give that a set of keywords that a good candidate must have in their resume as well as desired levels of experience with those qualifications.
2. As the HR partner looks at submitted resumes, they’re looking for the existence of my desired keywords. and, if a resume has them, then they try to get an idea of whether the candidate meets my overall criteria (years of experience, etc.)
3. My HR partner passes off selected resume to me. As I review them, I’m doing basically the same thing as the HR partner did; the only difference is that I understand the technical terms more than the HR person did:
   1. I screen a resume for the desired keywords
   2. If a resume has those keywords, I look for those keywords in the bullet points for the candidate’s various jobs to see when and where they used each skill that I’m interested in. I literally do CTRL + F for each keyword in the resume. I don’t even necessarily read the relevant bullet points, just confirm that the skill appears in recent job bullet points.
   3. If the resume makes it through the steps above, I actually spend the time to really read the resume in detail.

I spend literal seconds screening a resume

These days every opening gets hundreds of applicants. For the position I was hiring recently, we got over 400 applicants, and we didn’t promote or advertise the opening. Therefore, speed and efficiency is the focus of  the people doing the initial reviews, and it’s easiest to reject candidates for pretty much anything. When I’m doing a first-pass screen of applicants, I spend literal seconds on the keyword scanning and keyword matching phases, and I assume that my HR partner does the same. If I can’t easily find the keywords that I’m looking for, I reject the resume.

It’s the same for the keyword matching phase–where I try to figure out when and where a candidate used the skills that I’m looking for: if I can’t get a feel within a matter of seconds for when and where the candidate used the skills that I’m looking for, I toss the resume. As I review resumes for friends and ones submitted for my job opening, I’m amazed at the number of candidates who list a skill in their summary section but that skill does not appear elsewhere in their resume.

Formatting your resume for screening

If you’ve read this far, then the next section shouldn’t be a surprise: if your resume isn’t specifically formatted to make it easy to a.) find the relevant keywords and b.) to identify when and where you used skills and experiences, your resume will be tossed. Specifically:

• Facilitating keyword scanning: the first section below your name and contact info should be a summary of skills and experiences.
• Facilitating keyword matching: the bullet points for each past job should contain the relevant keywords for technologies and skills that you used in that job. I’ve seen some candidates go so far as to bold-face the relevant keywords in the bullet points. I love that because it just makes my job that much easier.

Outdated resume advice

As someone who’s been in the industry since before everything was electronic, I think a lot of common advice about resumes is a holdover from days of paper and is therefore not very relevant today:

Cover letters

In ye olden days before everything was electronic, it was quite common for paper copies of resumes to be passed around with little additional context. Say I go to a conference, have a conversation with someone and they give me their resume. I get home from the conference, sort through all the materials I picked up at the conference and don’t really remember who gave me this resume or why. In that scenario, a cover letter makes sense: it provides context for the resume.

In the modern world, however, resumes are rarely passed around without some kind of context. Take the same scenario about going to a conference: if I’m at a conference these days, that other person will not hand me a paper copy of their resume; most likely, they’ll send me an email and attach the resume. The email serves the same purpose as a cover letter used to: provide the context for the resume. In my opinion, the same applies most of the time with regard to submitting cover letters with job applications. I’ve not written a cover letter in decades, and I typically don’t read them when reviewing candidate profiles, but I’m sure there are some circumstances where they are still appropriate.

Career objective statements

My opinion about career objective statements on resumes is essentially the same as my opinion about cover letters. Back in the days of paper, career objective statements provided context that is rarely needed today.

One-page resumes

Back in the days when resumes were always printed, the possibility existed that additional pages of your resume could be misplaced, so a one-page resume served a very practical purpose. There are good arguments that your resume shouldn’t be too long, but in my opinion, there’s no good reason today to go to great lengths to keep your resume one page. And certainly do not sacrifice readability (“screen-ability”) just to keep your resume an arbitrary length.

Odds and Ends

I also have a few other miscellaneous opinions about resumes.

Avoid subjective statements about personal qualities

This is one of my pet peeves. I just viewed a few of the resumes that were submitted for the position that I was recently hiring for, and I immediately found some examples:

“A proactive team player with excellent problem-solving and communication skills, ensuring smooth collaboration with development, operations, and product teams.”

“Excellent analytical, problem-solving, communication, and interpersonal skills along with a good attitude for learning.”

“Detail-oriented approach adhering to timelines”

“Ability to work independently and participate in team environments”

I am strongly against using such statements in your resume: anyone can make such claims, they are very hard to impossible to validate in interviews, and they take up space in your resume that could be used for more quantifiable and directly relevant descriptions of your qualifications

Use industry-standard job titles

A resume is a marketing document, and the purpose of it is for people to get an idea of your skills and experiences at a glance. If you had cryptic or inaccurate job titles in  past, I advise you to use on your the industry-standard job titles that most accurately reflect the work that you performed in that job. When you fill out job applications or background check forms, you might want to use the actual job title. If someone asks about the discrepancy, just use the reasoning above. I have used this strategy for decades and in many cases, I no longer even remembered my official job titles, and nobody has ever asked about it, and it has never caused an issue with a background check.

Don’t list general skills

Here I’m talking specifically about adding skills such as “Proficient in Microsoft Office” (or substitute in any of the Office applications or other very general skills) unless they are directly relevant to your experience or the position you’re applying to. Otherwise, I assume that any knowledge worker can use these applications. And again, listing these skills that are common to all knowledge workers just takes up space that could be used for more relevant qualifications.

Use a very plain text-based format

I see a lot of resumes that use fancy formats with color, multiple columns, graphics indicating skill levels, etc. These formats presumably do not get parsed as well by applicant tracking systems, and in my opinion, this formatting hampers the keyword searching and keyword matching.

I see a lot of people online recommending using the Jake’s resume template in LaTeX, and I think that’s a good choice. Also, keeping the master copy of your resume in a structured format such as LaTeX ensures that formatting doesn’t hinder ATS parsing of the resume. Overleaf is an online LaTeX editor that offers a free tier for personal projects. I keep my master copy in very simplified HTML, using header tags appropriately to indicate document structure, and that has worked well for me. If I were starting from scratch today, I would use LaTeX format and Overleaf.

Always send your resume in PDF format

PDF format (sorry for the redundancy) was designed precisely for the use case of ensuring that a document looks the same regardless of the specifics of the device someone else is viewing it on. Do not send anyone your resume in Microsoft Word format. These days, with the popularity of online tools such as Google docs for creating and viewing documents, you can’t assume that people viewing your resume have Word installed. If, for instance, I open a Word document on my personal MacBook that doesn’t have Word installed, it will open in the Apple Pages application, and I’ve seen many instances where the Word formatting was butchered in Pages. Using PDF avoids such problems.

Here’s a mediocre example

I’ve tried to apply all of my own advice to my resume. I call it mediocre because I see a lot of things that I would like to improve, but I’m not job hunting at the moment, so I don’t feel the urgency at the moment to make the improvements.

NOTE: I’ve keep a copy of my resume on my personal web site, though I don’t think that’s a particularly relevant practice these days; I just continue it for continuity; I started the practice long ago and don’t see the need to take it down.

This reddit comment succinctly describes my experiences working in commercial software startups and, to a lesser degree, in established commercial software companies:

I’ve been in HCIT/Software for twenty years, and every time there was a major bug that caused a fiscal impact to the company when doing RCA, it always, 100% of the time happened because someone up on the food chain overwrote the decisions of the people who knew what the fuck they were doing.

I explained to him like this:

Salesman goes to a client and asks, “what will get you to buy this widget from me?”

Client replies “it has to do everything”

Salesman agrees.

Sales then delivers the requirement of everything to the product/project manager. PM then asks their team, “how long will it take to do all this?” The team will respond “eleventy years.”

PM goes back to sales to state it will take eleventy years, which of course isn’t good enough. PM asks sales then when do they need it by, which is always “immediately.”

PM goes back to their team, “What can you do by this date?” They respond with a much truncated list. PM provides it to Sales saying this is all they can deliver in that timeframe.

Sales then loses their shit, bitches to senior leadership if not all the way up to the C Levels, “We are gonna lose this huge ass sale because they cannot deliver everything by this date!”

So then the COO or SVP over development/production forces the team to just put out as much as they can by that date, so in order to do that and keep their jobs, corners are cut, QA is skimped, and you get a pile of widgets with an unacceptable defect percentage.

Then something breaks, everyone has to scramble to clean the mess, all the while the C Levels are blaming the development and operational teams and the sales guy is jerking off with the piles of cash from his commission and doesn’t give a shit, cause once the contract is signed it’s not his fucking problem anymore.

All the while the client really only wanted a widget that was affordable and worked.

Today, I ran across this web page touting the features of Microsoft FrontPage 98. Man, this brings back memories. My first job in software outside of computational linguistics was as a QA engineer on the development of AT&T’s Easy World Wide Web business web hosting service. In those early days of the web, AT&T’s assumption was that small business owners would pay $300/month to host their web site but develop the site themselves (In hindsight, that was a terrible assumption. As things settled down, web hosting became a nominal fee and sites were mostly designed by professional web designers). With this business model in mind, AT&T supported Microsoft FrontPage and NetObjects Fusion as WYSIWYG web development tools. AT&T’s service included a separate staging site for development with one-click deployment to production and unlimited telephone support (hence the high price).

Microsoft FrontPage 98 screenshot

FrontPage was widely hated due to its ugly templates, and that hate was justified. But it did so much more than that. It allowed you to create a web site structure automatically drag and drop  navigation to every page–navigation that was automatically updated when you added pages or changed the structure. Before this, you had to update every page individually (or use server side includes if you could program in PERL or shell). I learned to create individual page parts, e.g., banner, navigation, footer, etc, created a common template for all the pages in my site using those parts, and I could add pages, completely redo the look and feel (though the basic layout was limited to my template) of colors and images. It made managing web sites easy.

It also allowed the developer to include common interactive features such as hit counters, standard forms such as feedback forms and custom forms that either saved the posted results to a text file on the web server or emailed them to you. To be fair, these ‘bots,’ as they called them, required a web server running the FrontPage server extensions, but Microsoft supported extensions for its own IIS web server as well as other common web server software that ran at the time on UNIX and BSD systems (to be fair, the tool supported these other server architectures when Microsoft acquired it; if Microsoft had developed it themselves, I’m sure it would have only run with IIS).

You could edit your web pages in the WYSIWYG editor or edit the HTML directly, and what I found amazing at the time, you could switch between modes. If you added non-compliant HTML by hand, the editor didn’t complain about it and tried its best to display it as the browser would. Because HTML development was originally performed by hand without tools to validate the HTML, browsers and other tools had to be very tolerant of non-compliant HTML code.

I tested FrontPage support at AT&T and used it for several years for my own personal web development. This web site that I found brings back so many memories.

I received my Ph.D. in Germanic Studies from the University of Texas in 1997, but I work as a software quality assurance engineer. I do not directly use my language/culture/literature education in my work, but I started out as a computational linguist in jobs which very much required my educational background. I was recently invited to talk with the students currently enrolled in my graduate program about career opportunities outside of the academy. How could I offer any kind of advice when I didn’t really have any particular plan before the age of 30? After a lot of soul searching, I settled on describing it this way: I was the recipient of some significant good luck, but only because I was open to a variety of experiences did I take advantage of the luck when it presented itself.

The biggest break came after six years in grad school. I had completed my coursework, was working on my dissertation and was beginning to think about my longer-term future. I admitted that I wasn’t particularly passionate any longer about my academic area (if I’d ever been very passionate, to be honest). Therefore, there was no reason to believe that I would be among the smallish percentage of my peers who would get good jobs in academia. So, I made a conscious decision to open myself up to other opportunities. Very shortly after this self-confession, there was a part-time job opening for a English-to-German lexical coder and quality analyst with the Metal machine translation project (which was, at the time, owned by Siemens and maintained a development office at UT). To make a long story short, this job led to a full-time job as a software quality assurance engineer with  Logos machine translation and ultimately to my career as a software QA engineer.

As far as I know, I was the only one of 20 or so qualified grad students who applied for the Metal position. There are very few industry applications for my graduate education, and working in machine translation was one of them, but most of my peers were so focused on the very narrow path that was presented to them by their graduate program that they didn’t even think to try out this opportunity. Tellingly, when I decided to pursue this path instead of one directly in the academy, some of the faculty members in my program wrote me off. They didn’t consider my job as a computational linguist a valid career choice for my education.

So, my advice to the current grad students was to think more broadly of the skills that they’ve acquired in grad school and just to be open to the opportunities that fate places in our paths. You just never know what might come along, and if you’re not open to it, you might not recognize an interesting opportunity when it presents itself.

In 1997, I completed my Ph.D. in German literature/cultural studies/translation studies at the University of Texas at Austin. Here are the abstract and table of contents of my dissertation:

Abstract

The three dramas of nineteenth-century German playwright Georg Büchner represent an interesting case study of how literary reputations are made and how the value of literary texts is determined. This dissertation undertakes a detailed examination of the reception of Büchner’s dramas in Anglo-American culture from 1919, the year the first English-language translation of one of Büchner’s plays was published, through the 1960s, when Büchner had become an established part of the canon of world drama.

Employing a methodology based on the work of Hans Robert Jauß and Michel Foucault as well as several contemporary translation theorists, the goal of this dissertation is to investigate some of the factors that influenced the building of Büchner’s literary reputation in the United States and England. Based on the findings of this case study, it is also the goal of this dissertation to make a contribution to the on-going development of a non-normative, reception-oriented approach to translation studies.

The research of this dissertation is based primarily on the published English-language translations of the plays of Georg Büchner, the texts that were published with the translations, and the published reviews of the translations and performances of Büchner’s plays in the United States and England from the beginnings of the reception of Büchner’s works in England and the United States in the early twentieth century to the 1960s, when Büchner’s reputation had been well established in English-language culture.

Table of Contents

Chapter 1: Theoretical Groundwork

• Translation Study as a Linguistic Study
• Translation of “Sacred” or Canonical Texts
• Translation as a Process
• Translation as Rewriting
• The Power of Reception: The Cultural Turn in Translation Theory
• Translation and Horizons of Expectation: Histories of Reception
• Translations as Cultural Manipulation: Rewritings as Regimes of Truth
• From Theory to Practice: An Interim Conclusion

Chapter 2: German-language Büchners

• Büchner’s Life
• Early Failed Image: Büchner as Young German
• The Socialists’ Büchner
• Büchner for Social Democrats and Naturalists
• Büchner’s Reception in Germany: The Twentieth Century
• Conclusion

Chapter 3: Anglophone Büchners

• Büchner in America: The Socialists
• Büchner in the Early Twentieth-Century: The Great European
• Büchner in America: The German-English Version
• The Other English Büchner: Büchner after World War II
• Büchner and the Canon of World Theater
• Büchner and the 1960s
• Büchner as an English Classic: Conclusion

Chapter 4: Büchner as Reception Case Study

Appendix A: English-language Translations of Georg Büchner’s Works through 1980

Appendix B: Performances of Büchner’s Works in Britain and the United States through 1980

Works Cited

The next time a recruiter tries to entice me to the next hot startup (granted, that doesn’t happen very often these days), I think I’ll point them to this article when I decline: The “Crisis” in Venture Capital.

I’ve started a new blog that focuses on my professional interests as a software quality assurance engineer. Check it out: Agile Testing.

I received the following business contact (nice way to say spam from a legit company) to my small business email address this week:

Dear Stan:
It’s a pleasure getting connected with you. I am Pulakesh and am writing from Adea. Adea (www.adea.com) is a Texas based global IT Solutions & Services Company that leverages technology to create sustainable business value for clients and help them in their quest for improving business performance through a Global Engagement Model (GEM). Adea relies on its proprietary Global Engagement Modelâ„¢ (GEM) to deliver projects on time and within defined budgets. The GEM is a process driven framework that leverages the synergies of ProVedaâ„¢ – the Process Framework, OptiShoreâ„¢ – our Delivery Model and the ProSourceâ„¢ Business Model. All engagements at Adea, regardless of location or model, leverage GEM with more than 1,000 software professionals working in US, UK, India and China.

Man, I have no real idea what Adea does, and no real desire to find out.

This is a video that some coworkers and I created for a company short video contest (I’m ‘Waterfall’, if you don’t know me)

This blog entry, How to Improve your Skills at Office Politics, contains some very good advice for being successful at work, though I take issues with the author’s choice of the term ‘office politics.’ To me, that term has very negative connotations.
I’ve been thinking about these tips in regard to working in software quality assurance. One of the toughest office dynamics is between experienced, alpha geek developers and more junior and/or less technically skilled quality assurance engineers. As a QA lead, I spend a lot of my time helping both sides to bridge this gap.
One of the best skills a junior QA engineer can develop is knowing when and how to ask for help: before you ask a developer for help, make sure you’ve tried everything possible to figure it out or find out for yourself, and when you do ask for help, explain what steps you’ve taken. This explanation helps the developer to understand what you do and don’t know, but more importantly, it shows him that you’re taking initiative and not wasting his time by running to him first (I’m consciously using the male pronoun here, since such alpha developers are usually male).
I had one QA engineer who was having a particularly tough time gaining credibility with a senior developer on her team. Despite employing the tactics above, the developer was still giving the QA engineer the impression that she was annoying him. So I designated myself her safe go-to person. After trying everything she could think of, she would come to me without worrying about her credibility.
If I could help her, then she didn’t have to go the developer. If I couldn’t help her, then she didn’t have to go to the developer. If I couldn’t help, then I reinforced to the developer that she had taken a lot of initiative, and helped him to understand what she did and did know.