My wife is a chef. When she applies for a job, she goes to the restaurant for what’s called a staging. A staging is a practice shift, where you make some dishes with the other chefs you’ll be working with, and you’re evaluated by the su chef or executive chef. Is the restaurant owner in charge of hiring chefs? No. Are the investors involved in hiring? No. Is the hostess involved in hiring? No. The chef in charge of the kitchen hires kitchen staff.
Can you imagine how dysfunctional a restaurant kitchen would be if the waiters hired the chefs? Or if the manager who has no cooking experience managed the kitchen?
An engineer should be in charge of your engineering team, and they should be in charge of hiring the people working under them.
Which process would you rather be put through? Talk to dev manager and team earlier or filtered (and likely lost) in recruitings inbox? Would you rather be contacted by a recruiter? Or contacted by a dev on a team you might work for?
We certainly do both, but the best candidates come from being engaged in our tech communities and sharing our team and roles organically, rather than filtering through lots of resumes after a recruiter spams a bunch of people.
It varies at different stages of your company. You should measure where time is wasted and optimize.
If you're doing A) and you get a ton of clearly unqualified candidates, you want your dev team leads to do the initial assessment and the recruiter(s) to learn from that.
If, viceversa, you're doing B) and your dev team leads are spending most of their time recruiting, then you need to smooth into A).
As a good rule of thumb, during hiring season, the dev team leads should spend around 30% of their time on recruiting, not more than that. Less is always good, of course, but it shouldn't come at the price of wasting more time during longer interview cycles.
Yes I'm curious how this works. I don't expect a dev to be productive for some time, maybe months. And for isolated, self-contained tasks, like those that make a good intern project, it takes time & effort for the dev team to set those up so someone can be successful at it.
Generally the tryout projects are the projects the company is already working on and make the candidate work parallelly on them. After the try-out period is over they assess their work by comparing it with current team's work (obviously factoring in they were not working full-time)
This sounds interesting. It feels like you would have to have a super smooth on ramp to productivity, otherwise you are getting terrible signal from the try outs.
Ie. you don't want to hire dev A because it took them just 2 weeks to figure out how to deploy a change to Prod instead of 4.
Don't let the recruiter write the job description. Let the team/devs write the job description and then recruiter can fine tune it for presentation and delivery. Yes, this adds friction and in larger companies, may not even be possible but in smaller mid-size companies, recruiters should not be writing job descriptions.
Can you imagine how dysfunctional a restaurant kitchen would be if the waiters hired the chefs? Or if the manager who has no cooking experience managed the kitchen?
An engineer should be in charge of your engineering team, and they should be in charge of hiring the people working under them.