
Refactoring Back End Engineering Hiring at Slack - felixrieseberg
https://slack.engineering/refactoring-backend-engineering-hiring-at-slack-b53b1e0e7a3c
======
harel
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.

~~~
guitarbill
Agreed, if hiring processes involved less questions about CS/algorithms, and
more day-to-day skills like "use git to do <x>", "how would you unit test
this?", or "given these use-cases, how would you design the API?", a lot of
places would be hiring better engineers and building better products.

~~~
inertiatic
I don't think you build better products if you hire someone who knows how to
use git. It doesn't fit in with the rest of the skills you're listing.

~~~
degrews
I agree that testing for knowledge of specific tools is probably not what you
want, but I find that among people who do have significant experience with
git, ability to use it effectively seems to correlate pretty strongly with
overall programming ability and productivity.

I mainly have experience with git, but I assume this generalizes to other
version control systems. I also think that version control is a pretty
fundamental skill for software engineers (comparable to unit testing), so I
think substituting that for "use a version control system to do x" would fit
in with with other skills.

------
perfect_wave
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.

~~~
guitarbill
Currently, the existing form also has a bias - towards CS and top CS
universities. Yet I keep working with great self-taught engineers from a
variety of disciplines, some of whom don't even have degrees. Maybe a shift in
hiring wouldn't be a bad thing.

As for how, you could focus more on logical thinking, user experience
considerations, technical writing, or other, softer skills.

For a lot of grads, we already have to re-teach them the language, as
universities don't seem to give marks for consistent style/using
linters/unittesting/best practices/comments/writing documentation etc. In the
time it takes to break these bad habits, you can definitely teach somebody
who's technical and done a basic programming course a lot of things.

------
inertiatic
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.

------
monsieurbanana
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.

~~~
arduinomancer
That would be an interesting idea, having a dedicated refactoring person on a
team. I wonder how well that would help with tech debt...

~~~
dvtrn
I'm working through reading the DevOps Handbook (the companion successor to
The Phoenix Project), and in it is an entire chapter dedicated to the
necessity of dedicating either the time (measured in 20%) or dedicating a
small group of people who's express and specific charge is refactoring and
paying down technical debt.

They pointed to Nordstrom as an example of an enterprise organization who did
this as a part of their internal devops transformation, and it worked wonders
at the time when it was needed.

This team didn't tackle new user stories for feature additions or
enhancements, they didn't work on existing tickets. Their role was singularly
focused on identifying and making payments on technical debt and operational
enhancements.

Not every team can afford to focus an entire group of people to the task of
paying down technical debt, but what I did take from it is that every team
can't afford to _not_ dedicate _some_ time out of the week or month making
critical fixes where necessary.

------
malvosenior
_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.

~~~
yahnusername
I've worked at places where the managers hem and haw over firing someone even
going so far as to use passive-aggression to make them leave on their own. In
environments like that, the cost of hiring the wrong person is huge. It could
take a couple of quarters to shake the dead weight and the entire team
suffers.

I've also worked with managers who have no problem being the hatchet man and
it's great. They sniff out the losers, put them on a plan, and they're either
out the door soon after or stick around to get fired.

I would rather managers teach each other to wield the hatchet than try to get
seven steps ahead of a dud hire during the interview process. "Release early,
release often."

~~~
malvosenior
I totally agree. I think so much of the "it's really hard to get rid of bad
people" story comes from weak management. Firing people is part of the job,
you need to be comfortable doing it.

Interviewing people is _extremely_ disruptive to an engineer's time and in a
large company it could potentially happen a lot. I think that is the metric
that should be optimized for, not minimizing firing work for the hiring
manager.

~~~
ebiester
I wonder about this - am I doing a candidate a disservice by hiring them
without knowing that there is a non-trivial chance that they'll be fired
within 1-2 months? If someone doesn't already have a job, that's fine, but
someone might quit a situation where they are suited for one in which they
aren't. Or, if someone is a junior developer, they've just spent 2 months
before being let go, and has to explain the situation to the next place.

I care about the people I hire as humans and don't want to put them in a bad
situation.

~~~
malvosenior
I wouldn't say there's a non-trivial chance that they'll be fired in 1-2
months. Being able to effectively screen people is another technical
managerial skill. There is a very, very small percentage of candidates that
make it through the interview and later turn out to be duds.

I think there are two issues at play:

1\. Ineffective managers are terrified of firing people.

2\. Ineffective managers rightly or wrongly think they can't screen people
without code tests, white boarding...

Like I said in my original comment I look at their Github or any other work
portfolio they provide and have a deep discussion about it with them.

------
deegles
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.

------
thaumasiotes
> 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?

~~~
wolfgang42
Isn't that their point? The article is acknowledging that they had set their
expectations too high and so candidates were failing to meet one of the two
goals, which is part of why they redesigned the process.

~~~
thaumasiotes
But that problem doesn't require a process redesign. You can just lower your
expectations.

------
benmmurphy
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.

------
icodemuch
It gratifys me in some weird way to know that companies stress out about the
recruitment process at least as much as I do

------
satokema
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.

------
iandanforth
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.

------
purplezooey
"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.

------
sandGorgon
Anyone know what kind of review questions work well ? Any rule of thumbs, best
practices to create these questions?

Why do they work better ?

------
carimura
I was waiting for links to all the awesome [open source] code Slack talks
about in this post. I was sad.

------
ed_balls
> it would have taken a year to fill our existing open headcount

Maybe open an office in a different location or hire remote?

