Disagree with this, this is why the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews. Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.
Hiring is broken because engineers think it's just another problem you can apply typical engineering solution. Same kind of thinking that causes the terrible customer service in Google products like random algorithm locking out accounts.
I did a fair chunk of interviews when I was just a dev. I loved it, and I took it very seriously in terms of vetting programming skill and practices. I also felt good offloading that burden from a good manager.
What were your success rates compared to other teams who depended more on the manager for hiring? How often did your company fire people for poor performance?
Sorry, didn't mean these to come off so pointed, just super curious is all, not trying a gotcha or anything.
If you just chuck a random dev at the interviews sure. If you handover gently and make sure they've internalized your interviewing process it's a different equation.
In enterprise, I've mostly seen hiring broken because there isn't a dev in the room, just fluffy non-technical management.
> Hiring is too important to leave to engineers who don't want to do it.
Who says they don't want to? I'm an engineer, and I love doing interviews. Plenty of engineers are interested in human aspects of the job too, and would be greatful for the experience.
> Hiring is too important to leave to engineers who don't want to do it.
I'm trying to come up with a ballpark estimate of portion of co-workers who seemed entirely unconcerned about who potential new co-workers might be, and while a precise figure is going to be beyond me, it's probably close to an order of magnitude smaller than people who care somewhere between a bit and quite a bit.
Filtering out the people who don't care much also doesn't seem like it'd be a difficult problem: ask for assistance rather than assigning it.
Passion doesn't equal competence. It doesn't matter if they're passionate about doing interviews, sometimes that even makes it worse because they think they are raising the "hiring bar" but instead doing a really bad job at interviewing.
The disinterested engineer doing an interview is less harmful than this type of passionate engineer interviewing.
The current broken system started with Google. They had a hiring problem, too many candidates to interview. So what did they do? Apply principles used for scaling computer systems. Treat each employee engineer as a generic interviewer who can give a generic algorithm question. Scale across all engineering teams to handle the candidate load. That's the Google way, apply algorithmic scaling to everything.
It works except when the fundamental problem is a human issue like hiring and customer service. It's bad system but they get so many candidates it doesn't matter. And the company is successful, success hides all failures.
So other engineers in much smaller companies get asked to interview their future teammates. Sounds great in theory. But passionate or not, they have no idea how to do it. So they just cargo cult the big tech companies. Completely clueless copying of a system that was created for a problem they don't have (massive number of candidates).
Only the manager and lead engineer should be involved. They need to take back control and leave the juniors out of it.
So is the problem interviewing or is the problem cargo culting?
You dont get magically good at hiring because you are the manager or lead engineer, just like anyone else you have to practice and build skills towards this.
Dumping it on any level of engineer (or person) without education and training on how to conduct interviews will not yield good results.
There's a difference between "we are scaling this wrong" and "nobody knows how to do this thing" and "only the top boss should do this thing."
Some sr eng are great at team leading through interpersonal skills on top of technical, some are so good technically they lead their teams anyway, and I dont want the second group interviewing almost anyone.
> the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews
What industry? I've been a hiring manager for years and am not familiar with this happening.
> Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.
So ask them. If they don't want to do it, don't force them. Most DO want to do it, because they get to pick who they get to work with, and do a fantastic job contrary to what you're saying.
Random algorithms locking Google accounts is nothing at all like hiring and I am failing to see the parallel you're trying to illustrate.
Absolutely this. You will want the feedback from the existing team anyway right? Why not have them form their opinion first, and only talk to the candidates that pass their screening?
Somehow, I feel like this is starting to sound like managers shouldn't do any work.
Managers aren't supposed to be coding as their primary responsibility.
I mean if you can find someone willing to do managerial responsibilities, then go for it. Just make sure you're not the one taking advantage of them and reward them for it.
A leader's job should be to effectively delegate themselves out of a job. If you think delegating effectively isn't "work" then I don't know what to tell you.
Leaders are not effective if all they do is throw work over the wall expecting other people to do it. That's the quickest way to isolate yourself and is why managers often don't know what's going on in times of problems. It's also the quickest way to get employees to hate you because they view you as useless.
And this is especially true when its a task managers should be responsible for, like hiring people.
If the point is to make them have no job, then why are they even needed in the first place?
Work themselves out of a job, not necessarily delegate. The former could mean solving a problem once and for all, or putting process in place, or eliminating a task. The latter means having someone else do it.
Most times you are correct. In this scenario, however, it seems like he started as an individual contributor and transitioned to management. When that happens, in my experience, companies want to continue to leverage the system knowledge from the individual in some form of producing technical assets.
Hiring is broken because engineers think it's just another problem you can apply typical engineering solution. Same kind of thinking that causes the terrible customer service in Google products like random algorithm locking out accounts.