Would you rather spend an extra minute or two on the resume scan or an extra half an hour in the interview only to find that a month after you hired them, they're incapable of doing the job?
Careful where you think you're wasting time and effort.
Here's the problem with long resumes. Most people don't have anything useful to say. Most of the time when I see a resume of any length, they contain very little useful information. Longer resumes just make it worse. Now, there are ones that describe a project in detail, and you're like "Wow, that's really amazing." Most of the ones I've seen in the programming space are more akin to the 3 paragraph long description of writing stored procedures for a database. I include myself in this group, and that's why I keep it short.
Having a short resume is also a test I use. The hardest paper I ever wrote was in an advanced Psychology class where we had to perform some sort of analysis on a character in a book. The paper had to be at most 4 pages, for something that could have easily taken 10 or more. Understanding how to communicate effectively is one of the best skills that people can have. Do I discount people immediately for not being able to do this? No, but it is something I take note of when I see it.
The first litmus test in this situation is "Is this 6 page resume an engaging read that delivers everything useful effectively?"
If it doesn't and that is important to you, this isn't your person.
Equally, are you discounting this person just because you can't be bothered to spend an extra couple of minutes parsing their resume which upon closer inspection is solid gold?
Being concise and communicating effectively doesn't necessarily mean the same thing.
You would not believe how many resumes I've seen with things like formatting issues and misspellings. I'm picky about getting technical terms correctly, but I understand that everyone might not know there are capital letters in random places in words. If you're going to misspell something, at least be consistent (no joke, I've seen resumes with JavaScript, Javascript and Java Script, and like three sentences apart from each other). Going through 6 pages of that along with phrasing issues is brutally draining. If you have a long resume, give a summary or something of each entry, so I can choose to see if what you are describing is what I'm looking for. With all that being said, I'm pretty forgiving. I understand that if you have English as a second language, you might not know all the nuances to grammar. I get it. I try and give some flexibility.
So here's the thing, with all that in mind, you ask if I can't be bothered, no I can't. Just because someone spews something on a page and calls it a resume does not mean that I should take a look at it. Have some pride in what you send to people. Yes writing resumes suck, but that doesn't mean you shouldn't work at creating it. People say, "I don't know about design", or "I'm not a writer."
1. It's not that hard to understand the basics of design and layout. Buy a book. Read a website. Download a template off the internet.
2. Ask someone to look at it before you send it.
It doesn't have to be great, but it least make it look like you care enough about what you do to make it decent.
1. Decision fatigue
- A longer resume doesn't make the choice easier, it makes it harder because now I have more to compare and contrast more.
2. Half-life of knowledge
- I did computer vision about 5 years ago, but I leave it off my current resume because I know the field has changed so dramatically since I last did it that my knowledge of it is out of date.
I think your comment about computer vision illustrates what's wrong with this industry. If you were able to do computer vision 5 years ago you should be able to get up to speed now. This attitude doesn't allow most of to build a decent resume but instead we have to chase the latest tech all the time and none of our experience counts. For example I would prefer someone who worked on a big complex web site ten years ago with the tools available then over someone who has done a simple web site with the latest React version.
The half-life of knowledge is in the eye of the beholder. The field may have changed dramatically, the technology may have moved on. But much of what we know about how to design computer programs today hasn't changed as much as you think in 50 years. Frameworks have changed, architectures have changed, paradigms have remained very similar. Paradigms are the important part. Be as careful with what you choose to leave out as what you choose to include.
Careful where you think you're wasting time and effort.