Software developer since the 1970s.

First of all, any development experience from the 70s is at best meaningless and at worst detrimental. Try teaching a Cobol programmer OOP and you'll find that they learn it slower than someone without that procedural coding experience. Second of all, the first line of your resume should not be to announce what protected class(es) you are in. Your resume shouldn't have "senior citizen" on it anymore than it should have your race, creed, religion or any other irrelevant facts on it.

Linux work started with the first kernel releases and continued through Slackware

So what? I used Slackware extensively in 1996 but the experience is meaningless. If I had that on my resume now it would tell anyone reading it that I'm probably resting on my laurels and probably have for decades.

Experience includes: Agile, Assembly, Back-End, BSD, C, CSS, Debian, FOSS, GIMP, HTTP, Java, Linux, Mathematics, Mint, MySQL, Octave (similar to Matlab), Open Source, Parser, Perl, PHP5, Python, Recruiting, Regex, Shell, SQLite3, Support, TCP/IP, Ubuntu, UNIX, Tcl/Tk, Teaching, Training, Transcoding, VPS, Writing, XML, XSLT

I've seen dozens of resumes that list dozens of technologies like this. Not even so much as a bold font weight to say the things they are masters of as opposed to "experience with". Early in my management career I hired a developer that had TCP/IP programming listed as a skill on her resume. After hiring her, I gave her the IP address of the server to do some TCP/IP programming. She asked, "What is IP address?"

As someone who is in their 40s, my advice to to someone without a job later in life is to drop all the extraneous things and focus on what you've done lately. Lose the moniker "old coder". 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.

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.

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.

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.

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.

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.

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

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

Btw I use Perl 7 (Ruby)

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.

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.

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

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.

"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.

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.

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).

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.

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.

"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.

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.

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.

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!

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.

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.

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.

And what are those mistakes you keep alluding to?

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

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.

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.

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.

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.

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").

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#.

Over-engineered, massive codebases: job security.

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

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.

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.

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

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.

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.

This specific point is very important. Design your resume to save time for the recruiter. The recruiter has hundreds of resumes to parse. If you make the case you are a great match for the job opening in the first paragraph your chances of being noticed increase enormously. You are not telling who you are - you are selling a solution to a specific problem.

> If you are applying to a PHP job

There is little point in mentioning you wrote key parts of MVS/370 because the recruiter will have no idea what it is. If the company uses Ruby on Rails a demonstration of your expertise with JBOSS will be (correctly) treated as noise.

I think knowing C makes me a better Python programmer, but unless the job asks for it, I wouldn't mention it before the first technical interview with someone who agrees knowing C makes someone a better programmer.

Tip: using a spreadsheet to keep CV parts saves a ton of time.

Tip 2: find out who the recruiter is. If you can understand more about the person and his/her expectations and background, you may fine tune your CV even more perfectly.

Since you don't know which one, the letter or the CV, will be read first, you should optimize both.

I wrote an article a few weeks ago on the same topic which is relevant (http://lifehacker.com/tips-from-a-recruiter-dont-make-me-rea...)

Why do some companies not accept cover letters? For one, nobody wants to read them. Keep in mind, nobody wants to read cover letters OR resumes. They want to have a conversation, and they want to be able to determine as quickly and accurately as possible whether or not that conversation is worth having. This can be quite prone to bias.

Most cover letters simply reiterate what the resume says, but in a condensed format, along with some fluff about how hard they work and how strong their soft skills are. It's usually fairly pointless, and some companies ask for them as a bit of a test of your interest. Companies that don't ask for them likely don't feel they are useful, and would rather have their recruiters looking at resumes (and hopefully actually having conversations) than reading traditional formatted letters.

I usually keep it all in one LaTeX file, and abuse that as my macro processor (to include / exclude sections). Text files work well with version control.

so, experience will get you so far.

Help your candidates do the best they can. Don't set them up to fail at a task they weren't expecting.

And taking 2 minutes to actually look up the references is obviously too much work for a very hard working and responsible HR specialist.

It's triage. If you're in the stack, make sure you obviously belong in the next, smaller, stack. Repeat until you get an interview.

If you want to learn more about this topic, begin reading about statistics - especially type I errors and type II errors, since this is the mathematical formulation of the topic I was talking about in the previous paragraph.

I applied for a position at a company a year ago and was a great fit (both from my perspective and a company rep) but my salary expectation was higher than their budget. That position remained open on their website until about a week ago. What happened a week ago? They sent an email to my almamater highlighting the position and included their current salary range. Guess what - the salary I was asking for last year fell smack in the middle of that range and they were inundated with applications!

edit: silly typos!

So I'd tell him to lie to get that PHP job. It sucks for lots of reasons, but so many employers in the PHP space all have their heads up their garbage collectors.

1. a new graduate, in which case we need to be having a different sort of conversation than with an experienced hire, or;

2. a graybeard who hasn't looked for a while and doesn't realize how many more layers there are now between his initial resume and the hiring manager.

In the former case, the resume is going to be useless and I'd really rather there were a common format specifically for someone with very little work experience. And no, a transcript isn't useful, either, although it has strengths that a standard resume format doesn't.

In the latter case, these guys (and at 42, this is my cohort now) need to learn about the volume of incoming data, and how useless for decision purposes a 30 year large pile of acronyms is.

To nitpick one example, I've always felt that after your first job you should drastically cut down the importance of your degree on your resume. As far as I'm concerned your degree/major/whatever is a poor indicator of the kind of developer you're going to be, to be used only as a last resort when you are young and haven't had the chance to demonstrate yourself in the workforce. After that, your previous job titles/accomplishments are way more telling.

This guy is in his 50s and he's still got individual line items for honors and high honors. I don't care. I don't even know what that means back when he got his degree. He points out he has a double major. Then tells me his majors individually. Then tells me how he did in each major separately. This after the fact that he's already told me all this in his overview. This reads like a recent grad's section (look at me, I graduated!!!!). I half expected him to list projects he did in school (hell, maybe some of those projects at the bottom WERE school projects -- that's the mindset I'm put in by the schooling section).

Then he tells me his hobbies. This isn't as bad as telling me he likes to ride his bike or something, but "working on a couple of books" sounds so "I've been working on that big idea in my spare time for 10 years..." It conveys zero useful information to me. Clearly he has no finished books (because then he would have listed them, but somehow he is working on more than one at once). The ONLY thing interesting to me here is "Open Source projects". But thats lost in a bunch of stuff I don't care about. This should be ONE LINE which has specific github projects where I can go check out what he's done.

"MS-DOS, Win 3.1 through 7" Ugh. Unless your goal is to maintain old systems or something this just seems ridiculous.

Then you've got gems like "Voting Software; 50% of U.S. market" LOST in the stockpile of buzz words. Something like that should be a bullet point under the employer you did it under in the top section.

People go through hundreds of these things. This thing is visually exhausting. It doesn't read like a list, its jam-packed with information in different styles: top looks like an essay, then a list of short answers, then "how can I maximize information per square inch" at the bottom. I'm intimidated to read it.

Your overview should MAYBE be 3 sentences. Then immediately drop into the jobs you've had, with bullet points about interesting standout things done in them. Then ONE LINE with your degree to prove you have one, then maybe "skills" or whatever to fill out the bottom. If you've done your job right no one will be reading by then, you'll already have been placed in the "follow up" pile.

IMO this is stupid, self-destructive for companies and likely the result of cargo cult management.

My "generalist" palette is exactly what got me hired at each one of my previous jobs. I learned programming as a hobby long before going to university, and I got a degree in Instrumentation Engineering with what essentially amounts to a minor in Power Electronics. During the last two of my undergrad years I worked in a research team at my university and did a fairly good job (papers and all) in a third field, computational electromagnetism, mainly with applications in microelectronics.

This means, on one hand, that I can be very helpful to anyone in my team. I can help those of my colleagues who lean more towards software than hardware troubleshoot their instruments and development boards, and I can serve as a buffer between the hardware designers and the programmers. I can make good trade-offs between circuit-level design and high-level programming abstractions and I can design applications for low-power operation instead of writing something and tweaking it until it has decent battery life.

What this also means, though, is that people in management are ecstatic about how they can give me pretty much anything to work on, and I'll munch it, or stick me in the same room with people who think JS is the best thing and people who think computers are evil and still understand what each of them says. This enthusiasm comes from precisely the same people who whine about candidates who are "miles wide, inches deep", and I know of at least one instance when the lead developer who interviewed me had to kick and scream to get me hired because my CV painted me "undecided" and "not having a good career discipline". It's even more ironic considering that the people who whine about it are typically millimeters wide and deep.

I often hear this kind of discussion in the middle management circles. Our people are way too specialized and it makes communication and collaboration difficult; we could use people with a more diverse range of skills; we depend too much on one or two people doing this thing, but they're the only ones in the team who can do it. This is especially problematic in teams of people who have been in the company since they were juniors. Well no shit it is, since they just spent four out of the six years of their careers doing precisely the same thing.

And no, "side projects" are not a good solution to this, and I've walked out of interviews because of HR folks strongly implying that my side projects are for learning skills the company needs. Fuck off. Thinking and learning aren't free. You want it, you pay me.

I've walked out of interviews because of HR folks strongly implying that my side projects are for learning skills the company needs.

Could you explain what you mean here a little more? Did a company, at the interview phase, tell you they wanted you to work on side projects for free?

What they told me is that it's a good thing that I am familiar with so many technologies, since that probably indicates that I spend a lot of my own time perfecting my skills. Which is actually true. But then they began to rant about how that's a good thing because this is a competitive field and it's really hard to keep up with all the new technologies popping up, so I might have to put up some of my own time to learn the technologies we'll use.

I actually raised an eyebrow and said that no, I'm not willing to do that. This opened up a discussion about dedication and loving one's job beyond the matters of workhours and payment, which are true signs of a professional programmer, at which point I really just told them I'm not interested in their offer anymore and left.

At that point, I'd have left even if they'd have sworn I wouldn't have to do that and that they were just checking. It's really impolite. I don't presumptuously boast about how I know what really makes the difference between a professional medic and one who just has a license to practice. It's also manipulative in a really poor way, implying that if you don't do all that stuff, you're "just" a programmer, rather than a "professional" programmer. Yeah, no shit I'm a "professional programmer" -- I don't have kids, I live close to work, my girlfriend works from home so her schedule is more flexible than mine, everyone in my family is in good health and back in college I fucked up my sleep schedule so hard that the occasional all-nighter doesn't do much damage anymore. But I'm exactly as professional as the dude who comes in at 9 and leaves at 5 because his kids want their father, not his toys.

Companies use barely-functional pattern matching algorithms to automatically toss your resume into the garbage. It is very likely that any effort you spend hand-tailoring your self-advertisement will be wasted anyway. But let's assume that you're doing it to pass the bozo filter and talk to a real person.

If you have to feign specialization to get past the auto-rejector, it is safe to assume that the company sees fewer qualified candidates. Supply is lower. As long as the posting remains open, demand remains the same. Therefore, the more specialized the role, the higher your expected remuneration should be. It's fine that companies are picky, but not both picky and cheap.

My advice is to use a general, unmodified resume for all your initial applications, and only to tailor your resume if the company does not respond in person after the first 2 weeks. If that generates a response, remember to ask for a higher salary if you reach the negotiation phase.

Of course this, like most other advice, should be taken with skepticism, because it is based on my experiences, not yours.

Honestly, I don't spend much time customizing a resume, because I already have a job, even if I don't like it, and a lot of the postings that I see are just as flavorless and uninspired as an untailored resume. My primary criteria for applying are whether the job itself seems like it could be interesting after you subtract the HR boilerplate and whether the company makes it easy for people to submit themselves for consideration.

If applying is as easy as writing an e-mail with a resume attachment, I will take the time to write an original cover letter. If I have to jump through 8 pages of hoops where I have to re-enter my entire resume into a series of tiny text boxes, I will not customize anything. And on the 8th page, where I am asked to list 3 of my weaknesses in an HTML form, just above a request for my entire salary history, I will almost invariably list "I get snarky when confronted by foolish or wasteful hiring practices." At that point, I have already invested that much time on an application that I know will not yield fruit, so I can't help but feel bitter about the utter waste of it.

And that sets off all kinds of alarm bells, be it on a resume or on a job description.

If I get a resume like that, I'm assuming the applicant doesn't really want to work with us, they just want any job, and other than a paycheck they don't give a fuck about what we're offering.