I make it a point to not read resumes unless I'm supposed to be asking questions about their contents, to avoid bias.
You should be aware this is not unbiased, it's just biased towards those who happen to have worked on similar problems to what you think is important.
Google can probably get away with this due to the size of applicant pool, but when I see other companies cargo-culting this approach I can't help but see a huge talent arbitrage opportunity.
When i interview candidates today, i check a resume for 3 things: years they have been coding professionally, has their average tenure with companies been > 6-9 months, what languages do they list? It has yet to be a practice that has bitten me in any way i can identify. In fact, i feel i give candidates a better chance when im not criticizing their resume before meeting them.
1. https://blog.benroux.me/resumes-make-hiring-harder-ignore-th...
I’m very deliberately not sharing my personal opinions on this.
A screener's job is to read the resume and match static facts to company needs. A recruiter's job is to gauge subjective fit and mutual interest.
An interviewer's job is to assess analytical ability, communication skills, personality, and culture fit, as well as to be an advertisement for the company/team/project/position if both sides want to close the deal. None of that depends on a re-evaluation of the static facts on the resume.
If I interviewed with a CEO or VP of Engineering, and that person asked me questions about my resume, I'd run away as quickly as possible from that company. I'd do the same depending on the circumstances if an engineer referenced my resume during an interview.
I also found history the most boring subject in high school. Probably not a coincidence.
What else are they going to ask you about? If my resume highlights my notable accomplishments in XYZ and the VP of E asks me if I have any interest in doing XYZ then I am going to consider the VP of E to be a total idiot or incredibly distracted.
So I'll ask about XYZ', because that's what we're going to build.
(We're actually building ZYX''', but that's a secret we'll reveal once you join the team.)
I have had a pleasure of interviewing a 'veteran' who listed both Emacs and vim on his resume, among dozens of other keywords and many, many years of professional experience. I asked him, how do you exit these text editors? "As any other program", he answered, perplexed - "you click on the cross in the upper-right corner".
This was not an unique and ever especially outstanding event in my interviewing experience.
Any person who actually used either of these editors even once would have a pretty solid idea of what I was going for. It was a very simple, quick test to determine that he just assembled his CV from semi-relevant keywords at random.
You're right, it's technically possible, but the parent is justified in being really suspicious that someone is citing familiarity with both emacs and vim and is confused that there's a non-mouse way to do something.
The question would have been better if it was directed to an Emacs feature for which graphical versions didn’t obey ordinary Windows conventions.
Now, certainly, with the fancier GUIs you can absolutely use mouse inputs. But it's quite a bizarre scenario where someone would be using an interface narrowly optimized to use the keyboard for everything, and yet still consistently use the mouse to exit "like every other application". The reason you use emacs/vim is to keep your hands from having to leave the keyboard! Why would you do that and yet not use the standard command for quitting? Not even ctrl/cmd-Q?
The parent is right to be suspicious of someone claiming extensive emacs/vim experience while using the mouse as a default option for a frequent, required command.
FWIW: I'm a Macvim user that has never quit it by clicking an X even though I know it's possible (at least for the individual windows). Although also FWIW I don't use the vim window feature and would fail questions about that.
In the last set of interviews I had to do, I've ended up doing the role of talking to people about the technologies listed on their CV and asking them detailed questions to find out just how well they really know them. This just because I happened to be the person in our company who knew a little bit about most of the things that the people we were interviewing claimed to be good at.
Sometimes you have a really nice technical conversation with them and discover that they're clever and knowledgable. Sometimes you uncover a blagger trying their luck. Sometimes a bit of both. So, it's a useful part of the interview I think.
So very recently we interviewed someone with 30+ years of experience, more than any programmer at our company (only 3 developers), and much more than myself (8 years).
So I went away and did a little bit of research about the technologies he'd talked about: COM and Corba and JBoss and other artefacts 80s and 90s, and tried to ask some questions in as respectful a way as I good, and I hope he wasn't too annoyed. In the end he was great (actually I found his enthusiasm and attention to detail pretty inspiring) and we hired him.
I can definitely see how a person would be annoyed by that sort of probing though, especially when the interviewer doesn't know what they're talking about.
But, what's the alternative?
If you ask both candidates a question like "Johnny climbed up to the top of the hill, where was Johnny when he stopped climbing?" and then get a blank stare from both candidates then you are going to conclude that you can't find any 'qualified' candidates because they can't answer a dead-simple question.
The vetting of candidates used to be contributions to software product releases and publications (in addition to degrees and GPA). A motivated hiring manager could also search mail archives of popular open-source projects.
For the technical interviewer knowing a bit about the candidate can help to start in an area where the candidate should have experience and then move into the direction you are interviewing for, of you have a clear set of requirements for the job however can also directly start there.
I'm not following. Why would someone read the resume to someone else?
There's actually not a whole lot of reason for me to look at their resume. The group who makes hiring decisions has it, so my interpretation of it won't be that valuable. Potentially I could ask them to elaborate on some of their prior work or projects, but that's usually less meaningful than just asking technical questions.
(Not trying to claim that I'm actually able to figure out much of anything in a technical interview, but that's the goal.)
No, and that's called due diligence. Same with hiring. I have come across enough candidates where there was a huge gap between claims written on the CV and what the candidate actually did or knew to blindly trust any CV.
And the best candidates are often not the best CV writers.