The Great Resume Rewrite

I spent all day writing.

But it had to be done.

My work. My way. My resume.

Because MWMW ("My work, done My way") is the Golden Key to happiness. (But we'll blog about about that another time).

I don't have very many regrets in life, but one of them is that I didn't reject the irrational advice and conventions that got imposed on my resume through the years, both by well-meaning and trusted advisors, recruiters, employers, and so forth. That will never happen again. Because from now on, it's MWMY. You know what I'm talking about:

• Ridiculous and contrived stylistic conventions, such as omitting the subject of a bullet point, because that subject happens to be yourself, repeatedly.
• Boilerplate text, cliches, corporate-speak, and management buzzwords. 
• Evasion, manipulation, and "spin."
• Arbitrary length prescriptions.
• A bureaucratic tone attempting convey objectivity and solidity, but in reality conveying stodginess and stupidity.

So I took out my resume, started right from the top and rewrote it straight the way down. I found I had to do in in several passes. Each time I came back to the top and restarted, it got better. And it just keep getting better and better.

I mentioned before, in my post where I resolve to do this rewrite, that I would report back on the results. To quote myself, which seems fun:

Contrarian resume is coming. I'm going to be 100 percent grammatical, spelling out the first person for every one of my many accomplishments. It's all about me, as indeed it should be, being my resume, so "I" and "me" are going to be a major element. (I'll report here later with the final count, so be sure to check back here in a couple of days.) I also will pay no attention to length at all. I will only concern myself with showcasing relevant experience. If I fall one word over to another page, that's the way it's going to be distributed. If it takes 10 pages, so be it. I'm going to highlight my short-term projects, as well, by explaining that the instability was the clients, not mine. I might even mention that I resent them for it.

In short it's going to be fresh, honest, clear, relevant, personal, non-deceitful. It's going to be a blast to write it.

So this is fun time;  review time!

And, there are all kinds of interesting results and things to reflect on, as well! For instance, have you ever noticed how easy it is to just glibly throw out a statement about something you're going to do, and then, later, you find out that "the devil is in the details?"  This coming note is a great example of that, and a good illustration to pass on to management about how surprises often arise, despite our best intentions and often things are not as simple as we always assume.

I realized, in attempting to count my use of "I", the following:

• Simple word-finding/word-counting doesn't work well on the document, because "I" is a letter component of many words, and gets caught by the count programs in places where it should not get counted.
• Me, however, also needs to be counted.
• So also, do contractions, such as:
• I'm
• I'd
• I'll

I ended up hand-counting about 60 self-references using variations of the 1st person-pronoun. So that's pretty good. I imagine that would raise a red-flag with the scanning software that started me down this pathway. 

The length of the resume, including all the relevant material I wished to include ran well over the conventional recommendations.  I hit 4 pages, double the conventional Whiz-dumb. 

Just to establish that these conventions are commonplace, and held even by the best of people, here is what Cracking the Coding interview says -- a book I highly recommend, by the way, not for it's resume advice, but for it's approach to career development and interview questions:

In the US, it is strongly advised to keep a resume to one page if you have less than ten years experience, and no more than two pages otherwise. Why is this? Here are two great reasons:

• Recruiters only spend a fixed amount of time (about 20 seconds) looking at your resume. If you limit the content to the most impressive items, the recruiter is sure to see them. Adding additional items just distracts the recruiter from what you'd really like them to see.

• Some people just flat out refuse to read long resumes. Do you really want to risk having your resume tossed for this reason.

If you are thinking right now that you have too much experience and can't fit it all on one page, trust me you can. Everyone says this at first. Long resumes are not a reflection of having tons of experience; they're a reflection of not understanding how to prioritize content.

As you saw in my former posting, I'm a contrarian about this advice. Does that mean that I'm not reasonable about it? Far from it! Here is the logic of the way I think, formulated into a response to the above:

Yes, I'm in US, and I do indeed wish I could be in the UK instead, where a Curriculum Vitae is commonplace. But since we're stuck with the US, and I agree with your assessment that recruiters, and for that matter, the actual people hiring spend only 20 seconds or less, "looking at [my] resume." I will note a point or two. 

I tend to think that far less than 20 seconds is spent. Probably between zero and seven seconds. I base this estimate on the kind of queries I receive by email from recruiters who have "searched" my resume. Further support for this estimate comes from the number one, almost universal first question which hiring interviewers always ask: "I know I have your resume here, BUT would you please describe your recent experience for me first, before we get started discussing the details ..."  

If I limit the content, as you suggest, the recruiter (or hirer) is still NOT going to see the most impressive items. He's never going to see them. Adding additional items will NOT be a distraction, because there has never been attention focused on the document in the first place. 

Furthermore,  if someone "flat-out" refuses to read a "long" resume -- and I challenge the notion that ANYTHING over a page or two can be, by any stretch of the imagination, considered "long," I want them to toss it. 

I'm interested in working with people who are able to  read, like to read, and, frankly, are not burdened by supporting detail and explanation. By the way, will the analysis documentation and specification of the software I produce be less than a page or two? Does it show a failure to properly delimit, prioritize and hierarchically organize if my documentation is longer than a page or two?

Finally, I would like to address the issue mentioned about prioritizing content. I agree that prioritizing content is extremely important. And for this reason, I do employ the reverse chronological method which is common and conventional. Experience becomes increasingly irrelevant as it ages, and so this approach allows a natural and organic tapering of emphasis. The reader can decide for himself at what point the experience becomes no longer relevant for consideration. Yet he can, if he wishes, follow the logic of the career path back from it's origins. Since this convention has a rationale, I will retain it.

After adding myself back into my resume and adopting a human tone, my resume is such a pleasure to read. I read every word of it out loud to myself before sending it on to the recruiter. The honesty of the whole document is just so refreshing. For instance, here are two of my favorite snippets:

• When this naughty Government Sponsored Entity got caught cooking the books, I was brought in to provide a rules-engine based effort to re-cook those books, by reposting every trade from the bond model to the sub ledger and general ledger.

• Naturally, my on-shore team had to re-develop everything “delivered” by the offshore team. 

I Remain,

TheHackerCIO

Some REST for the Wicked

The wicked coders at Dev Talk LA started a REST book the night before last. Discussion was amazing. First we covered the paper on functional programming, which we didn't get to last week. This paper is a response to another paper, so you should read both. Then we did chapter 1 of the REST book.

One fellow geek brought his date to the Meetup -- this was his date night entertainment! I hate getting pushed off my UberGeek pedestal, but stuff happens! I look forward to seeing the happy couple at future Meetups.

I was kind of blindsided by one discussion, which mentioned "traits" with Java. I never heard of them. That's pretty weird for a java techno-maven such as myself, so I need to follow that up with him. And Google didn't help me out this morning, either. It seems "traits" might be another term for "mixins," which were found in some OO environments, but never in Java. Mixins were/are a kind of inheritance where multiple inheritance didn't quite fit the bill. I'm not sure if he's thinking of AOP and mixing the notion in with traits, but it's something to check up on. Or it could be some kind of a library that offers this kind of support in the java ecosystem.

Someone else mentioned GPars, a concurrency framework used in Groovy quite a bit. I don't know that much about Groovy, so this one  has to be put down on my "to be investigated list." I already spent a few minutes Googling it, and it appears to be an implementation of the "actors" abstraction from Scala and Erlang, but in the Groovy/Java world. I definitely need to spend some time playing with Groovy and taking advantage of it's type-inferencing, so I can avoid boilerplate code more. That just needs to happen. Because speed matters.

Another member highly recommended a concurrency talk by Doug Lea. From what he said, I believe that this is the talk.

Moving on to the REST book, the bid system got completely hijacked! Normally, everyone offers page "bids," and the lowest bid wins. But this time, one of our members just jumped in and pushed the last page of the chapter as the opening round!

The discussion focused on a Members key problem with REST for him in his work and in general., which was to get the human readable and machine readable representations integrated. For instance, he hates the whole embedding of versions into the URL for APIs. This is ugly and hard to support. Instead, if you traverse from the top of the hierarchy, and have clients parse a page of "billboard" information, which describes the kinds of additional services and methods available in the API (at that version), then you can completely avoid this.  You are basically building the API spec into the page returned, which the client reads, scrapes, and uses to invoke the various additional API calls.

The problem is, this scheme doesn't allow permalinks and the use of bookmarked pages in the browser. You have to start at the top of the hierarchy and traverse it, because the site might have been reorganized since the last time your client noted a permalink.

But it occurred to us that you could have a versionless permalink API, that mapped permalinks to whatever new, reorganized location they now properly dwelt in. And that would effectively take care of most of the whole issue.

We still need to get our heads wrapped around the right way to do all of this, but the book promises to help us immensely in that regards.

I Remain,

TheHackerCIO

Silicon Valley Via HBO

Pied Piper Website

Television is a hateful thing most of the time for TheHackerCIO. Whenever I'm watching the vapid content, I'm sure to have a laptop with me so I can learn something or try out a technique. BTW, you should always be coding on your laptop: during meetings, TV, listening to a presentation. All those wasted gaps of time can be easily redeemed by coding. It's a tremendously helpful habit.

But last night was different. I downloaded and watched the first episode of Silicon Valley. Geeks everywhere are talking about it, here and here, for instance. I loved it. I'm ordering HBO for the first time.

You can watch the first episode on the HBO Website.

If you're still unable to decode the characters, this page will help you.

In my opinion, they've nailed the culture. They've clearly done their research. Even my kid said, "They're just like those Hackathons you do." And that's reason to love it.

I remain,

TheHackerCIO

A Contrarian Resume

"Contrarians" are a kind of investor who wager against the conventional wisdom. Of course, the words extends beyond just the financial world.

TheHackerCIO is a contrarian.  

He sees no reason to respect conventional wisdom. Historical tradition isn't enough to justify decisions, policies, or edicts. They must be reality based. They must be true. They must make sense. They must have reasons and good ones that justify their prescriptions.  Otherwise, it's time to ignore them, or defy them with everything you've got.

ManagementSpeak, for example is the accepted convention.  Wikipedia explains that:

Corporate jargon, variously known as corporate speak, corporate lingo, business speak, business jargon, management speak, workplace jargon, or commercialese, is the jargon often used in large corporations, bureaucracies, and similar workplaces.^[1][2] It may be characterised by sometimes-unwieldy elaborations of common English phrases, acting to conceal the real meaning of what is being said. It is contrasted with plain English.

Readers of TheHackerCIO will recognize this as the  language of the Bloated Behemoth Enterprise. One of many pathologies found there.

This one has to be opposed with everything you've got. Why? Because it has evil purposes: dishonesty, evasion, pretense, concealment of truth, deliberate confusion to distract, or at best, a lack of candor, openness, or transparency.

And one of the most pernicious effects of ManagementSpeak is the nearly universal impact on resumes:

• Boilerplate is mandatory. 
• Never use a personal pronoun. 
• Only 3rd person. 
• Use acronyms to blast the brain. 
• Ungrammatical Bullet points describing accomplishments which never even feature a subject, but start off with a verb, such as
• Analyzed requirements with end users

                     instead of

• I analyzed and discussed requirements and features with key users.

•  Then, since the result is so mind-stultifying, no more than 2 pages of that, thank you very much.

What brought this to mind was that I applied for a job. The e-submission had a check box for a free resume evaluation, so I unchecked that box, having no desire for more spam to deal with. Naturally, the software ignored my selection and the next morning I had my free evaluation. I immediately clicked the link to unsubscribe, and haven't been troubled again, luckily.

But ...

I read their "eval." ; and it was evil.

They wanted $300 to fix these problems:
1. It was too long.
2. It had a personal pronoun.
3. There were deceitful ways to as they put it "minimize," short term assignments.

Needless to say, TheHackerCIO isn't coughing up hundreds of bucks to get his resume into conventional shitform. But he has been acutely aware that rewrite-time was nearing. Now I just have to do it. Starting as soon as I post this, I'll be doing a full top-to-bottom rewrite.

Contrarian resume is coming. I'm going to be 100 percent grammatical, spelling out the first person for every one of my many accomplishments. It's all about me, as indeed it should be, being my resume, so "I" and "me" are going to be a major element. (I'll report here later with the final count, so be sure to check back here in a couple of days. UPDATE 2014-05-02: I counted at least 60 instances of self-reference, including I, Me, I'll, I'd, and so forth. ) I also will pay no attention to length at all. I will only concern myself with showcasing relevant experience. If I fall one word over to another page, that's the way it's going to be distributed. If it takes 10 pages, so be it. I'm going to highlight my short-term projects, as well, by explaining that the instability was the clients, not mine. I might even mention that I resent them for it.

In short it's going to be fresh, honest, clear, relevant, personal, non-deceitful. It's going to be a blast to write it.

Never yield to evil. It leaves a bad taste. And you won't find happiness that way...

I Remain,

TheHackerCIO