I'd say I'm in a qualitatively similar position as you. If I'm going to interact with a candidate in any capacity, I always spend at least 30 seconds to skim their resume if I have the means to.
When I'm acting as a hiring manager for a role, I read through applicant's materials in detail before deciding whether to advance them in the process. It's at least 50% of my work time, and my technical work suffers. I communicate that to the relevant managers and stake holders, and they can help decide whether it's the best use of my time.
I also regularly receive followup emails from rejected candidates saying that they thought the interview was the most fair and thorough of anywhere they applied, they understood why they didn't get the job, and in the process they learned where they need to focus on to be a better fit for the same type of role in the future.
Yes, I'm not usually in this role. I don't find managers conducting technical interviews a good use of time, they are better spent on soft skills -- discussing previous projects, career goals, assessing team fit, answering questions about company culture/comp/perks/etc.
> I read through applicant's materials in detail before deciding whether to advance them in the process.
I don't usually filter candidates in this way. Recruiters send us candidates that are eligible for a phone/video screen, i.e. do they meet the hiring criteria. This is where the resume/materials are looked at. The resume is also useful to figure out where to funnel inbound candidates -- are they backend engineers, frontend, etc. It depends on the hiring pipeline.
In any case, from a purely technical evaluation perspective, the resume is inconsequential. Where did you go to school? How many jobs have you had? What awards have you won? Literally none of this matters and is utterly meaningless when it comes to your ability to do work with me and my colleagues. Resumes are ripe with bias-footguns that I try very hard to avoid -- cronyism, elite education, privilege, wealth, immigrant status, etc.
In my experience, and the experience of the majority of my employers and colleagues, it's more fair to evaluate without this information. The red flags and strong positive/negative signals are elsewhere. The resume is almost entirely useless.
> It's at least 50% of my work time, and my technical work suffers.
I would suggest closer partnership with your recruiting team and trying to communicate what you are looking for more succinctly to them so that they can deliver you a stack of candidates worth talking to. If you are at a remotely large company (>1000 employees) then unless you are bootstrapping a new team/org/whatever you shouldn't be spending this much time hiring. Your team is going to suffer.
> I also regularly receive followup emails from rejected candidates saying that they thought the interview was the most fair and thorough of anywhere they applied, they understood why they didn't get the job, and in the process they learned where they need to focus on to be a better fit for the same type of role in the future.
To be honest, we get the same feedback. Most candidates tell me that it's the best process they've ever experienced.
Each organization is going to do things differently obviously. To clarify, a hiring manager within my context is the person that's responsible for the process of hiring for a specific role. We almost always have individual technical contributors act as hiring managers. They set the technical bar, design interview plans, and act as a consistent point of contact for the candidate. Team managers are distinct from that, although they may be the ones pushing to hire to fill a role for their team.
In my experience, relying on recruiters to filter out candidates into a "high quality" pile isn't effective. That's where the resume bias tends to slip in.
Individual contributors spending time recruiting is also organization specific. I'm probably considered the highest value software engineer on my team. Part of that is because I actively work to make sure I'm replaceable. Most projects I've worked on are documented and tested enough that other engineers can step in and take over as needed. I also often turn down fun projects in favor of mentoring more junior coworkers to do them. On the hiring side, we maintain a high bar and hire for long term success. As a result, I trust everyone on the team to keep the ship on course.
> To clarify, a hiring manager within my context is the person that's responsible for the process of hiring for a specific role.
> ...
> Team managers are distinct from that, although they may be the ones pushing to hire to fill a role for their team.
I haven't encountered this before.
> In my experience, relying on recruiters to filter out candidates into a "high quality" pile isn't effective. That's where the resume bias tends to slip in.
I agree but I haven't seen anywhere (large companies) where this doesn't happen. There's always some intermediary filter before the resumes end up in the hands of technical staff.
I can't imagine why having recruiters involved prevents any of the other things you mention. ICs can design interview loops, help write job postings, work with recruiters to define and clarify what they are looking for.
Regarding your last paragraph, that sounds like the basic bar for most senior/staff engineer positions I've encountered. You're a force multiplier for others. That's the job.
When I'm acting as a hiring manager for a role, I read through applicant's materials in detail before deciding whether to advance them in the process. It's at least 50% of my work time, and my technical work suffers. I communicate that to the relevant managers and stake holders, and they can help decide whether it's the best use of my time.
I also regularly receive followup emails from rejected candidates saying that they thought the interview was the most fair and thorough of anywhere they applied, they understood why they didn't get the job, and in the process they learned where they need to focus on to be a better fit for the same type of role in the future.