There's been a lot of threads like this recently that discuss changing the hiring process to more closely resemble day to day work and working with an actual codebase.
My question is how does this work for new grads and people that haven't worked in the industry before? Are they using these new techniques to hire recent graduates/people that haven't worked as a software dev before? Does this kind of process adversely effect those who haven't worked as a software dev before?
I'm not trying to say that algorithmic/leetcode type problems are a better solution, but rather questioning whether this form of interviewing has some kind of bias.
Code review assignments are so much better than coding assignments that for me it's a great sign that your hiring sucks if you haven't switched to them.
If you do a large coding assignment you have to leave the time frame rather open ended to assist candidates that have limited free time. Instead this forces every candidate to spend as much time as possible to get noticed, having an opposite effect. There is no obvious solution to that apart from doing short timed assignments.
But what is even more important, a code review can be tailored to provide the same information on technical expertise, has a more natural effort limit and more importantly, it actually tells you about how that person will act as a coworker.
Will they even explain their work? Will they provide reasonable feedback, and will their way of explaining their thoughts in written word be detailed enough to guide people through?
Not only are code reviews, for myself, essentially part of the documentation of the code base itself, but they are also a very important communication channel. And how one communicates with others through it is a great proxy about how they will handle the rest of their communication.
I've never worked with an engineer that was considerate, kind and detailed (with a focus on being understood) in their review comments or presentation, who turned out to be an asshole when interacting with through other channels.
I thought this was a job offer for an engineer whose main job would be refactoring back-end code.
Turns out it's just another article about how to interview people.
chief among them is the high cost of hiring the wrong person, or missing out on the right one.
As a hiring manager, I've never cargo culted this particular view. In fact I think it's completely misguided. I always work in at-will states, it's trivially easy to let someone go. I also personally have no problem doing it.
I generally will hire based on conversation alone (no coding tests). If you ask someone detailed questions about work a candidate has done you can get a really good idea if they know what they're talking about. I know people say that they've interviewed people that can talk a good game but can't code a for loop once in the door, but I've interviewed hundreds of people and I can't say this is often the case.
Easy in, easy out. You know what though? There's very rarely ever the out part. If I can look at your Github, like what I see and you can back that up in a conversation, you're hired. That has worked out really well for me and reduces a lot of friction and wasted time (mine and other engineers') during the hiring process.
The moral of my story is that just because Google or some other tech giant espouses a theory like "false positives are way more costly than false negatives", it doesn't mean it works for all organizations or that it's even true at all.
It would be interesting to see a follow up a year or so from now about how candidates that went through this vs. the previous process are performing.
> Our take-home exercise, while loved by many, was also time-consuming. Its open-ended qualities meant that candidates, wanting to show off their best work, could end up spending many more hours of their own time to complete it than we had expected.
> This was often a barrier for candidates who couldn’t afford to invest the time needed to complete the exercise to our desired level of quality.
Isn't there a conflict here? Why are you setting the bar for your own desired level of quality so high that it isn't possible to meet it in the amount of time you expect people to take?
that github api is really interesting. does github never run GC on repos or do they flag the commits you create from the API so they are never GC'd? I guess in a normal workflow and normal git gc options commits that are unrooted would not be deleted because git avoids deleting recent data during GC. however, there doesn't seem to be any warning in the API that your commits might disappear if you don't root them.
It gratifys me in some weird way to know that companies stress out about the recruitment process at least as much as I do
Would love to work at one of these magical companies that HN posters work for that have zero internal domain knowledge required, zero runway time to the engineers being maximally productive, and zero friction teams where adding or removing any given engineer has zero cost for anyone.
The term "signal" is ill-defined in this piece. Are there other posts where they go into this in detail?
The decrease in the hard time-to-hire metric was great to see. This is a real problem with some top-tier shops.
"a high degree of craftsmanship"? I know what this means but still, how exactly do you define that and not be biased by how the candidate presents him/herself.
Anyone know what kind of review questions work well ? Any rule of thumbs, best practices to create these questions?
Why do they work better ?
I was waiting for links to all the awesome [open source] code Slack talks about in this post. I was sad.
> it would have taken a year to fill our existing open headcount
Maybe open an office in a different location or hire remote?
There is one thing mentioned there that I've never considered for some reason (and it's quite obvious in retrospect): Giving a candidate a code review exercise instead of (or in addition to) a code writing one. A code review can reveal a lot of how a candidate pays attention to details, looks at (and deals with) other people's code, reads code etc.