Hacker News Reader

The interest is appreciated. However, we have different perspectives.

My 'C' experience dates back to 1976 and is probably still relevant. FWIW I never did much COBOL though my firm did have a COBOL-Lint.

I don't think that your 20 years of Linux experience, or mine, is "meaningless". Not if the experience has been continuous. And, in my case, I've not only used Linux almost daily since before Slackware existed, I've developed my own distro, I maintain copies of nearly 2,000 packages, and many of my copies have patches of my own design.

Regarding the "masters of" issue, I may not have made the "generalist" point in the post clear enough. I'm only a "master of" a few things. But I'm very good at getting back up to speed on the things that I've had "experience with".

This is what a generalist does.

I agree with the "Take off your reasons" point. I'm going to keep most of the rest. The difficulties that I'm facing are partly due to my own foolish mistakes. But they aren't about the fact that I've listed hobbies on my resume or that I have a nick that implies age.

I'm not going to pretend to be a twenty-something specialist. It isn't what I am. I'm a highly experienced generalist. In this context, the decades that you feel that I ought to hide are relevant.

For some perspective... I'm 49. Last time I looked for a job (six months ago), I had two offers in less than two weeks. In general, I can get a job in no more than three weeks, just by answering the calls. And I don't think I'm all that special.

What I do have is a relevant resume, both buzzword compliant and impressive to humans who actually know their ass from a hole in the ground. It's carefully honed not to present me as a "generalist" (or some other self-perception), but to get me to the top of that pile for interviews.

Look at your resume as a piece of software. No matter how aesthetically pleasing and warmfuzzy your resume feels to you, if it isn't working, then it's buggy and needs fixed.

If I was a recruiter, this would go in the not interested heap.

While some companies want generalists, this isn't tailored for that either. You indicate projects you've been on, but not what your specific responsibilities were. Describing the project's language, DB, and how the project is pipelined is not useful. What did -you- do? What experience do -you- now have that could translate to other projects? "Core was a Perl server that collected binary data from upstream devices, stored data using SQL, and relayed it to clients as XML over HTTP." tells me about the project, but not what -you- did, not what experiences -you- now have. Even better if you can highlight keywords for me. The whole 'typical projects' section is kind of a waste; it's project names that have no meaning to me, or which may, but tell me nothing about what technology you know. 'Email client programs'; does that mean you have familiarity with the various email protocols? TCP/IP? GUI development? Nothing anywhere else tells me what it is you know.

Most companies want to fill a niche. Highlight what niche you can fill (yes, preferably tailored for the company), and make that -obvious- in your resume.

In general, take this approach - assume a recruiter, HR person, etc, will spend 3 seconds looking at your resume before deciding whether to bin it, or continue reading it. They are looking to match a certain set of relevant keywords/terms. What message do you want to send to someone in three seconds/what words/terms do you want to be matched against? That should be what I as a reader get from the first sentence, the first item in your experience, and the first item in your skills.

The message you're currently sending is "Old coder, part of a large team that did...some stuff that isn't spelled out clearly, and generalist with a whole lot of bullet points". Not interested. But tell me "Perl, C, and Linux expert, extensive application development experience, double CS/Math major", and suddenly if I have a Perl or C codebase I'm interested. Right now I have to do too much reading and thinking to get that information out, and no recruiter will do that.

Also, in general, you are correct that there is a bias against age. You're making it so the first thing I notice is your age. Make it so the first thing I notice is your experience; make it clear that you fill the niche I have, that you may well be the ideal candidate for my needs, BEFORE I notice your age.

These points are sensible. But aren't you simply confirming what I said to begin with?

You're essentially saying that companies use checkbox filters to sift through applicants looking for specialists. Exactly what I was trying to say myself.

The solution that you propose is to create a targeted resume.

But I've worked on hundreds of projects. Many of which used technologies that are no longer relevant Is it possible for me to produce a tailored resume based on perhaps one project from 20 years ago that matches a specific niche?

It doesn't seem likely. So most firms are going to be out of reach. I'll need to acquire more specialties. Or identify firms that are interested in generalists.

You're making excuses. Stop it.

You are not a highly skilled generalist. That implies you are a master of everything. You are not because no one is. Being a master of a few things with experience with many things makes you a useful specialist. The proverbial T shaped person. This is a good thing.

Highlight the things you are actually very good at, put the rest as experience. It looks like you've written a lot of Perl, so you're highlight that. Highlight Linux package management. Despite what you think, these are specializations.

Yes; you're correct about the "highly skilled" part. I should edit the point. I'm a highly experienced generalist as opposed to a highly skilled one.

You're also correct about the fact that I do have a few specialties, including Linux and Perl. I'm pretty good at a number of languages, but Perl has been a favorite for 20 years.

Perl is friendly and fierce Perl all problems shall pierce Perl is the duct tape That holds together all things Of Perl we sings

Perl is all things beautiful and bright Perl is a magical sight Perl each day and each night

:P

Site reliability engineering could be an option: fixing other people's code to work and run cheaper at scale.

For devs, it's important to have a github or similar because that's your real tech resume.

Btw I use Perl 7 (Ruby)

As a generalist myself, usually what other people consider "master of" I consider "back to speed in a few weeks." So I claim mastery on my resume because "mastery" is highly subjective.

For example, with my current position one of the reasons I got the job was that I claimed to be an expert with C++. Before jumping into this role it had been 5+ years since I had done any real work in C++. Shortly after joining I was asked to assist on a project written primarily in C++. Any time you join a new project there is some onboarding to learn how things are done in that project. I was able to get back to speed with the language and ecosystem within the period expected for onboarding. I was complimented on my expertise of C++.

I believe I am a seasoned software developer who has attained a fairly high level of mastery in the core skills required to build highly-complex software systems. Yet if I were to compare myself to some of my coworkers in the past I would be hesitant to call myself an expert on a particular subject like embedded programming (for example). However I claim to have this expertise on my resume as I have done quite a bit of embedded work in the past and I am familiar enough with that type of development to ramp up quickly again.

So even though I perceive myself as a generalist, many times my resume looks like that of a specialist. I am comfortable making these claims because I know I can deliver on them. You have to separate your self-evaluation (in which I tend to take a humble view of my abilities: that which I do not know vastly outweighs that which I do) from your self-presentation (in which I will make the boldest claim I believe I can support). Long years of experience are extremely relevant, but you have to connect the dots on your resume, you can't rely on the recruiter or hiring manager to see the intrinsic benefit of your experience.

You sound like a "T-shaped" guy: Broad knowledge and skills, with actual expertise of a few areas. Some companies, such as Valve, actually seek that. Have you sought them out? (I'm guessing that you have, but who knows…)

T-shaped is a good term. Thanks, I'll remember it.

I'm only now learning the ropes as far as some things go. I haven't sought out firms of that type yet and advice would be appreciated.

ZURB and IDEO too

http://zurb.com/article/11/the-t-in-team

Here's how I look at it: The only job of your resume is to get an interview. So whether the knowledge is relevant doesn't matter - the only question is whether it'll help you'll get to the interview. And from that view, I agree with your parent and 300bps' comments.

Over time, it's hard not to become a highly experienced generalist if you're good at what you do.

When a developer starts out its easy to find and beat a tribal drum of specializing in a few things.

This is often due to only having one or two cycles of learning and experiencing "a few years specializing in x". Add to the mix the veiled glorification of the twenties as a magical time to go hard (where ultimately everyone goes home), it can become an incredibly distracting echo chamber that one has arrived.

Something happens every few years though on the path of being a specialist, you get deep enough into one skill that it overlaps into another skill. The specific few skills collected in the first few years, become a specific 5-10 with equal depth.

Take someone who has developed 15 to 40 years and imagine how many cycles of learning they have been through to implement similar algorithms in multiple syntaxes.

That's someone I want to learn from when I shape my aporoaches, instead of having to feed my own snowflake quotient to relearn the same lessons before me.

As a polyglot, I've been programing for 20 years and am only in my mid-30's. Most developers will end up the same. way I've ended up with enough web, desktop and mobile development, along with the hardware and networking experience that building these solutions once required in addition to programming alone. It's full stack across hardware and software and networking, not the full-stack of frontend and backend dev that specialists espouse as full stack. I sure as hell didn't plan on this path, maybe it's the path of a lifelong problem solver.

One thing that some twenty something specialists may not yet have noticed is that programming is a separate skill from the syntax of any given language. The experience of figuring out how to do what you already know in a new syntax. It seems there can be more fascination in recreating libraries that have existed for decades, but not what the next leap is.

There's a fundamental mistake most recruiters are making too. They aren't qualified or trained to hire for technical positions. In the hiring I do and references I give, recruiters are generally clueless without their checklist. Programming isn't a skill like knowing how to drive a forklift. It's much deeper, and with the correct type of polyglot developer much more transferable between languages.

I'm inclined to work with an experienced generalist more often than not because I prefer to work with others who not only keep up, but help lead the strategic charge. Depending on the problem, younger specialists often go through relearning what experience has already taught. Both skillsets are valuable and necessary on any team, but I have my preference.

My advice, is to consider focus on a highly fluid and evolving area of technology that is in high demand, pays well, and you can effortlessly pick up. It's where you're talents shine. One area is mobile development. Build some projects and spin current skills into the next area. It will better highlight your ability to integrate everything from top to bottom.

I admire and am in respect of your experience and journey through creating so many solutions. If there's an interest to connect offline I'd love to learn more about your story to see if I may be able to help and if I may be able to learn more from your experience.

Will anyone who is half good at what they do will end up in any different situation than this in 20 years? Our creators need to keep creating. Maybe there is an evolution and growth needed in our field for the highly experienced.

"any development experience from the 70s is at best meaningless and at worst detrimental"

"but the experience is meaningless"

Taking that approach, almost all experiences are 'meaningless' in the context of "i need someone to do these exact steps XYZ". But, as someone who was programming (hobby) in the 80s, I think there's some value here (and of course I don't think it's purely defensive and me-focused, but maybe it is).

You mentioned elsewhere "Drop the me of 30 years ago into the technology environment of today and I would be completely lost." Perhaps, but many people today are completely lost too. The "you" of 30 years ago had characteristics - curiosity, problem-solving, etc - that informed the experiences. Over time, perseverance was demonstrated with an accumulation of related experiences.

The specific experiences of programming in 1985 are not relevant to most problems of today, but a demonstrated history of successful logical thinking applied to a variety of computers/data/projects is not irrelevant nor meaningless.

EDIT: Rereading the second half of your post, I agree with you on the second half - drop hobbies, drop older tech references, etc - lose the extraneous stuff in general from general purpose resumes. Lose date references in general, I think (graduation dates, etc). Focus on things that are relevant to modern work practices/tools.

Perhaps you were meaning all that older stuff is meaningless in terms of a resume? I agree. It's the sort of stuff that might come out in an interview or two, depending on who you're talking with. Telling a 24 year old about doing C64 assembly programming does no good, and wastes time - that is essentially meaningless in terms of general tech job hunting. There are rooms for these nuggets, but you need to be selective.

The "you" of 30 years ago had characteristics - curiosity, problem-solving, etc - that informed the experiences.

As I said in that other comment, I see the basis of your argument. Having learned many languages over a 30 year time frame shows you probably are a hard worker that keeps their skills up to date.

You know what shows that with almost no doubt though? When you submit a resume to an employer in 2014 and you show a mastery of commonly used 2014 technologies. That literally is the only thing that matters to most employers.

So yeah, if one (not speaking of OP) does not have experience with modern languages or frameworks for whatever reason, you can make an argument that your previous experience might hint that you possess desirable traits. But unless you're looking for maintenance job on some old Cobol or C code, there's nothing betting than keeping your skills up to date continuously which proves you have those desirable traits.

Again, in principle I don't disagree with your point. The danger is in the reverse - someone hired because they know tech 2013X, but don't really know how to do anything else with it, nor how to problem solve. At the same time, someone with 20 years of experience who perhaps just finished up working with tech from 2010, because that's what that client/company was using, and gets ignored as "not modern".

But your bigger point - yes - have modern skills, and being able to show those with relatively current tech is the best way to go. Personally, I'd take someone who is older but within a few years of current tech vs less experiences with only modern tech. 8 years of Java and Ruby with experience up to Rails 3 vs 1 year of Rails 4 only? Should be a no brainer for most situations, unless the job is "writing Rails 4 tutorials" ;)

There's a huge spectrum of middle ground there, and good companies/recruiters should be able to divine that. ("should" being the operative word).

There's a big difference between listing Rails (a new technology -even rails 1 is a new technology- that is currently widely used), and listing COBOL. Don't even bother listing cobol/perl/whatever unless the company you are using uses those technologies.

I think it's more about being able to distinguish skills from products. Products become obsolete, skills do not.

You have dBase II experience? Not relevant.

You have experience building database-backed interactive applications in resource-constrained environments? Could be quite relevant, with the rise of mobile.

So: go through the list of products and cull the old ones, but as you do so, ask yourself what you learned from using each.

I think it's probably best to split the job search into two bits.

a) The bit where some recruiter is looking through CV's. b) The bit when you talk to the gaffer.

I agree with the 'drop everything off a cv' line. Most recruiters have at best a basic understanding of IT buzzwords and next to no IQ. Keep it simple, sell yourself as the answer to the problem and save the interesting chat about what you did in 1987 for more important people.

> First of all, any development experience from the 70s is at best meaningless and at worst detrimental.

"Hmm, this Brian Kernighan fellow is going in the reject pile, since he worked with this 'UNIX' and this 'C' in the 1970's, and clearly his experience is at best meaningless and at worst detrimental. And this Vint Cerf character... we don't want to hire someone who didn't grow up using the internet!"

This sort of thinking is toxic to the industry, and prevents software development from becoming a proper engineering field. It prevents the development of institutional knowledge and stagnates forward progress. It's why the industry keeps rehashing the same memes in new fashions. It's why everyone thinks the latest JS shit is cutting edge, when it's just a warmed over re-skinning of fundamentally 1980's technology: http://en.wikipedia.org/wiki/Self_%28programming_language%29.

Every generation thinks their ideas are new. When in reality it's all the same thing, just recycled. Sure computers are smaller, faster, and cheaper - but fundamentally, the systems today are the same as the systems in 1985.

We have 4th generation languages today that are really just front-ends to c; created to make it easier for the masses to write code. Which is a good thing, cause I'm 50, and I remember the days working in the cold, dark basement walled off from the rest of the company.

I find it funny listening to the "youngsters" talking about the great new thing of today; be it agile, the cloud, or whatever. But I remember I was saying the same type of bs when I was 25.

Why's Brian Kernighan's resume going in the slush pile with everybody else's.

"Try teaching a Cobol programmer OOP and you'll find that they learn it slower than someone without that procedural coding experience."

Have you any evidence to back this up, as it sound like rubbish to me. I learned Java as my first language, and basically used it as a procedural language, until the OOP parts started to make sense. I don't see how knowing COBOL will make you slower at learning an OOP language.

> I don't see how knowing COBOL will make you slower at learning an OOP language.

what a lot of employers don't want to do is to pay somebody to learn on the job. It sucks, because such an employer is a good one, but to people who don't care, and is in need of a job getting done, they just see it as extra cost and lost productivity. Why hire somebody smart who can learn fast (and thus can adapt to new roles as they come), when you can pay someone with the _exact_ experience at solving your current problem!

Of course, this is probably a major contributing factor to companies having trouble hiring programmers. Finding someone with the exact experience of your current problem is actually pretty difficult.

Its kind of stupid really.

In my past maintenance programming jobs, I would say it took 6 months to get up to speed. I would put less than two months of that down to new languages. Most of it is getting to know the code that is already written (and usually poorly documented) and some of it is gaining domain knowledge.

Had to reply, could not agree more. People may hate it but there is an art to writing a resume and it's focus, just like a company needs to focus, so do you to get a job.

It's a fact of life that resumes are crucial and that structure makes a difference. But I've noticed that people often disagree about approaches.

This particular resume is based on a template that people in a channel liked. I've received a number of compliments IRL regarding both the layout and the content.

The only thing that people IRL seem to agree should go is the part about reasons for leaving.

The resume does need a new release. For example, I should start to fill in the years after 2009. But it isn't the resume that's the primary issue here. It's the fact that the market has shifted away from generalists, combined with mistakes that I've made.

FWIW, I've heard multiple recruiters and managers/directors compliment me on my resume style [1]. It's a bit more narrative and a bit less focused on bulleting out skills. This seems to attract more progressive forward thinkers (if you're into those sorts of companies).

At the same time, it does highlight my skills at the top of each area of experience, so some developers reading my resume may skim over the narrative part, focusing on the listed skills. So it works for them too.

It's also quite honest in a few areas that may turn off some people, but to me, it turns off the right people (those I don't want to work for).

[1] Check it out in my profile if you're interested.

That sounds about right. In my experience most recruiters are only capable of matching two words, with very little understanding of what the words actually mean. They have no idea that RDBMS / Oracle/ SQL are synonymous to a degree.

Be careful about trusting compliments people give you when they're physically standing in front of you. When people are looking you in the eye, they tend to tell you what they think you want to hear. Online communication creates a distance that makes people more likely to speak their mind.

Do you write your resumes to get compliments or to get job interviews?

And what are those mistakes you keep alluding to?

Are you saying that in 30 years all experience you have accumulated up to now will be completely irrelevant? It all depends on how continuous and recent your "current" expertise is. Someone 10 years retired suddenly looking for a job will do worse. Someone who had been actively honing their skills for 30-40 years is going to be the rockstar everyone wants and cannot find.

Think about it this way: would you rather have a fresh out of school or a veteran mechanic work on your car?

Are you saying that in 30 years all experience you have accumulated up to now will be completely irrelevant?

30 years ago I was coding in BASIC and 6502 Assembly on my Commodore 64. That's also around the time I got my first modem - a Mitey Mo 300 bps modem on my Commodore 64. It was before the Hayes Compatible days of modems so you had to POKE and PEEK registers to control it or get data from it.

To answer your question, that experience is totally irrelevant. Drop the me of 30 years ago into the technology environment of today and I would be completely lost.

I've been in IT professionally since I was 17 years old. The hardest lesson I had to learn was to let go of the past. Almost every major mistake I've made in my career was caused by me wanting to stay in the comfort zone of already known technologies. My years of installing Novell Netware 2.15 off 360k floppies just aren't relevant to the MVC web coding I do today. I was a Certified Netware Engineer (CNE) in 1990. It was the hottest technical certification on the planet back then. Should I put that on my resume today? Of course not, it's totally irrelevant.

The years I spent with Borland Turbo-C, Borland C++, Turbo-PASCAL, etc. just aren't relevant either. In fact, my opinion is that knowing those languages made it harder to learn newer languages. One could argue that listing 100 languages shows the skill to learn new languages but nothing shows that better than being an expert at a modern language. There's no better thing for an old coder than to really master a modern language and framework and to present that succinctly on their resume.

Think about it this way: would you rather have a fresh out of school or a veteran mechanic work on your car?

This is actually a good analogy, but says the opposite of what you think it does. If I had an old out of date car, I'd want the veteran mechanic to work on it. If I had a modern car run by computer chips, I'd want the guy fresh out of school.

Sorry, I don't agree. I have not been in the industry for 30 years, but I have been programming since a very young age on similar hardware to your Commodore 64. No I cannot translate the skills I learned when writing Basic for that 8 bit architecture directly to the modern web app project I am working on. I can however relate better to memory constrained environments such as Arduino's and MSP430's. I can say that getting started with a very limited piece of hardware and a very limited language did get my interest peaked to keep exploring what I could do.

Later I got into Linux and FreeBSD. While I have never worked with any BSD professionally (other than OS X, but that doesn't count), I do think that knowing how FreeBSD works makes me a better Linux user/admin/developer. Certain ideas (kqueue, core system vs packages, etc.) are good concepts to keep in mind when developing for a platform that does not have them.

I also learned Turbo-PASCAL and used Delphi for a spell. While not directly relevant, they did have quite an influence on today's languages and development environments. NetBeans which I did use professionally for a bit was a far cry form Deplhi but knowing both made NetBeans easier to use.

But all that aside, the point of having years of experience is not about enhancing your current knowledge. It's about enhancing the process of acquiring knowledge, organizing it, and using it. Someone that knows JavaScript is going to get coded under the table by someone who knows JavaScript, C, Haskell, Erlang, Lisp, Python, etc. In fact I would wager that someone who knew C, Haskell, Erlang, Lisp, and Python but not JavaScript would in the long run beat out a JavaScript expert simply because the penalty to learn a new paradigm is much smaller than perceived, while the benefit of being able to think in a multi-paradigm fashion is a huge benefit.

Finally, the mechanic thing: I am comparing a veteran mechanic, with say 20 years experience, including current experience with latest cars vs a mechanic with 1 year experience with just modern cars. I listen to CarTalk, the NPR program, and they had a few very interesting stories on there. For example, there was a woman who called and said that whenever she turned on the fans in her car it smelled like gasoline and it very often happened after she got her car worked on at the dealership. The suggested reason was that when the mechanic worked on it, he put dirty parts on the cowl of the car where the air intake is and some gasoline and oil dripped into it. This is something experience teaches you and it has nothing to do with the modern chips.

25 years ago, I was programming in C, Scheme, Common Lisp and Prolog (some Pascal, too, but I don't think that has aged as well).

Drop me of 25 years ago into today's coding environment, everything is just a lot easier. Java is intentionally designed to be as close to C syntax as possible, but much easier to get right (garbage collection!). For a class project, we implemented an object system in Scheme, so I understood OO concepts, again much easier today when it's already baked into a language. Ruby, Python and Javascript don't have much beyond what was in Scheme and CL back then in terms of concepts, just maps the same concepts to an Algol syntax. Prolog concepts show up in various languages from time to time (pattern matching in functional languages seems to match the part of my brain I remember using when writing Prolog).

Source code management, IDEs, continuous integration, all things that just make a developer's life easier than back then.

So, no, frankly, I honestly don't think the me of 25 years ago would have much trouble getting up to speed and being productive writing code today. What the me of today offers over the me of 25 years ago is skills for thinking about big picture design and architecture, building software as part of a team, understanding requirements, estimation and planning. The technology part, though, certainly isn't harder to understand today than it was back then.

> My years of installing Novell Netware 2.15 off 360k floppies just aren't relevant to the MVC web coding I do today.

The deep and abiding irony of your post is that MVC was invented in the 1970's for Smalltalk.

> One could argue that listing 100 languages shows the skill to learn new languages but nothing shows that better than being an expert at a modern language.

Unless by "modern language" you mean Idris or Agda or the like, you're barking up the wrong tree.

> This is actually a good analogy, but says the opposite of what you think it does. If I had an old out of date car, I'd want the veteran mechanic to work on it. If I had a modern car run by computer chips, I'd want the guy fresh out of school.

The more appropriate analogy in reference to Ruby/Python/JS/etc is that you bring a 1980's Chevette into the shop on top of which you've glued the sheetmetal from a late-model Aveo.

"One could argue that listing 100 languages shows the skill to learn new languages but nothing shows that better than being an expert at a modern language."

I think it's important to show both breadth and depth, and to be up front about how much you have of each. I don't list every language I've ever touched, but those I've used at least recently enough to be able to brush up on quickly I group into three categories ("fluent", "conversant", "familiar").

> The years I spent with Borland Turbo-C, Borland C++, Turbo-PASCAL, etc. just aren't relevant either.

Actually, my experience with Turbo Pascal helped a great deal when I moved on to Java. And I still believe that Turbo Pascal, in particular, would have been a tremendous help if I opted to pick up C#, because one of the leads of TP is one of the designers of C#.

I've been working at a large dotcom lately and one thing I've noticed is how much enterprise Java code starts to resemble Cobol after enough time. "Separation of Concerns" starts to look like Cobol's "Divisions," excessive amounts of boilerplate, etc.

Comments that add no value while the hard stuff isn't documented: knowledge hoarding.

Over-engineered, massive codebases: job security.

>> Lose any technologies older than a decade from your resume. Lose any references to "35 years of experience with...". Take off your hobbies. Take off your reasons for leaving your past employment. There are too many other fixes needed to go into.

And in that process lose any traits that might command a premium? Do senior developers not deserve to be compensated according to their experience?

You tailor your CV to the job. The CV is to get you the interview. The interview is to get you the job. The pay negotiations happen later.

Any job is a premium over "jack shit."

300, can you recommend a preferred way of listing technologies on a resume? I've struggled with how to show what I'm proficient at, versus what I'm only familiar with. Mainly because I don't want to be the only resume admitting only slight knowledge of tech x,y,z whereas everyone else is "experienced with" them.

Then drop the `slight knowledge of' bits. Resumes are not judged by number of bullet points. Just like with any writing, a big part of success is to cut, cut, cut.

I advise you to also: "Take off the bureaucratic hats".

If a developer has source code/projects available, why only look at his resume? Look at what he's DONE, and take your judgment from there.

also, quite important to the style: leave that 1st person "I" away. Every time when I read a resume like this I see a much overrated person, full of him/herself, former glory seeking new validation, etc. A big sign DON'T HIRE.

Hints: make it simple, objective, no complex sentence structures, just information to the job and assignment. Use nice fonts and do not clutter the information, structure it with max 2 headings.

So you see how difficult it is to please armchair psychologists: leaving out the first person pronoun from sentences is also considered bad style by some (with the suggested pseudo objectivity). Others conclude even that the person has no self esteem etc etc.

A resume is about the person presenting him/herself, isn't it?

I personally leave out "I", but yes, I have seen HR professionals suggest that you leave it in for the reasons you just stated (lack of self-confidence).

This is why it's important for hiring companies to have an open mind, for both their sake and the candidate's. Yes, a resume should be well-written, to the point, and free of errors, but realizing that everyone has their own idiosyncrasies will go a long way.

Agree with rewording the narrative part but not sure yet of the best way to handle some parts.

An advice I have been given is, "don't break expectations". I'm not talking about the content, which can easily have good surprises. I'm talking about the form. There, conformity is probably king. This means things like being a young white male with short hair.

Breaking conventions in your résumé can elicit positive reactions, or catch someone's attention. But it will often elicit such a strong negative reaction that your reader even look at the content. This thread alone contains examples of this.

For instance, saying "I" in the resume is breaking a convention. Nobody will reject you for not writing "I". But some will reject you for being cocky or narcissistic, or whatever. Same for your recommendation citation. It is not expected in the résumé, it is expected in a separate reference. (Edit: that last one may be an obviously good surprise, though.)

Try making a boring, conventional résumé. It should give you a second point of reference, and may help you out of a local maximum.