The best people for certain jobs may not have perfect résumés. Oh, sure, they’ll have the skills you need, but you might spot a “their” that should be “there” or vice versa. Many hiring managers reject such people on the spot. Research suggests that this may be a bad idea.
Typos are made because we’re so busy trying to convey meaning that we don’t always notice when we’ve made an error. We all know that it’s difficult to catch our own typos, but why is that? It’s because we already know what we mean, so our eyes read one thing but our brain translates it into the meaning that it already knows exists.
This, of course, means our readers have to extract our meaning without the benefit of being inside our head. Plus, they can’t see our facial expressions or hear our tone of voice as they can when we speak. This is why some people can give fantastic speeches and yet be awful writers.
So, writing–good writing–is hard to achieve. And résumés and cover letters are writing devoid of any human interaction. All the recruiter or hiring manager sees is what is on the screen and that may have their/there/they’re, your/you’re, and lose/loose errors. (Fortunately, most word processing software will put a nice red line under misspellings, which therefore don’t come up as often.) And when we see this, we reject candidates.
These errors, though, in no way indicate a lack of intelligence or even attention to detail. They do indicate a person who is very interested in getting concepts and ideas down on paper. Wired interviewed psychologist Tom Stafford, who studies typos, and described it this way:
As with all high level tasks, your brain generalizes simple, component parts (like turning letters into words and words into sentences) so it can focus on more complex tasks (like combining sentences into complex ideas). “We don’t catch every detail, we’re not like computers or NSA databases,” said Stafford. “Rather, we take in sensory information and combine it with what we expect, and we extract meaning.” When we’re reading other peoples’ work, this helps us arrive at meaning faster by using less brain power. When we’re proofreading our own work, we know the meaning we want to convey. Because we expect that meaning to be there, it’s easier for us to miss when parts (or all) of it are absent. The reason we don’t see our own typos is that what we see on the screen is competing with the version that exists in our heads.
If you’re hiring a proofreader, a their/there mistake can be a big deal. But if you’re hiring someone who is an idea generator? Such a mistake is just not that important. The question is, was meaning conveyed?
But don’t you want detail-oriented people? Well, of course you do, if you’re hiring a copy editor. If you’re not? This is not a critical skill. Do you want to reject the marketing guy with great ideas that will allow your company to leapfrog over your competitors because he messed up a homophone? What about the computer programmer who is expected to sit back and code? Does it really matter if he knows when to use “affect” versus “effect”? And can you tell if that was a typo or an actual lack of knowledge? Just by reading a résumé or cover letter, you can’t.
So often what we do in hiring is look for any excuse at all not to hire someone. Instead of having a human who can glean meaning from a bunch of words on a page, we run it through a key word search, which doesn’t get meaning, just key words. And, then, we hit “reject!” as often as possible. When the computer spits out 15 résumés with the right key words, we then go through and look to reject as many of those as possible as well. Typo? Rejected. Wrong school? Rejected. Didn’t work for the right company? Rejected. Six months of unemployment? Rejected.
When we’re hiring, we should be focused on the meaning conveyed in the résumé, and not on how we can reject as many people as possible. A typo doesn’t mean someone is going to be a bad employee. In fact, it can mean that he or she is so focused on conveying meaning that you should bring that person on board as soon as possible.
This article originally appeared at Inc.