8 ms·

Refactoring Back End Engineering Hiring at Slack

monsieurbanana 8y ago
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.
- CodeCube 8y ago
  lol, I thought the exact same thing
- arduinomancer 8y ago
  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 8y ago
    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.
deegles 8y ago
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.
malvosenior 8y ago
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 8y ago
  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 8y ago
    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.
harel 8y ago
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 8y ago
  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 8y ago
    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.
    - xemdetia 8y ago
      I would disagree when it's a clear requirement of the work to be done (and often tossed haphazardly onto a resume). There can be some real time sinks that are not towards making someone productive in a code base as you have to stop and teach them how to think about Git. There's also the fun of having to use advanced Git magic to untangle their PR into something sensible because they've done odd merges along the way where they should have rebased their commits. People that still are from centralized source control only world still exist and getting them to work Git well is a skill that's worth interviewing/filtering over if it's a day 0 expectation.
    - degrews 8y ago
      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.
benmmurphy 8y ago
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.
ed_balls 8y ago
> it would have taken a year to fill our existing open headcount Maybe open an office in a different location or hire remote?
perfect_wave 8y ago
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.
- 52-6F-62 8y ago
  > questioning whether this form of interviewing has some kind of bias. In the case above—the bias is toward experience. I don't think that's a bad thing. Context is important, however. I haven't read any Slack postings, but if they're asking for tangible experience this kind of gatekeeping makes more sense than textbook questions. If they're hiring for an entry-level role then a different approach might be merited.
- guitarbill 8y ago
  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.
purplezooey 8y ago
"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.
satokema 8y ago
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.
thaumasiotes 8y ago
> 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 8y ago
  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 8y ago
    But that problem doesn't require a process redesign. You can just lower your expectations.
sandGorgon 8y ago
Anyone know what kind of review questions work well ? Any rule of thumbs, best practices to create these questions? Why do they work better ?
iandanforth 8y ago
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.
inertiatic 8y ago
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.
icodemuch 8y ago
It gratifys me in some weird way to know that companies stress out about the recruitment process at least as much as I do
carimura 8y ago
I was waiting for links to all the awesome [open source] code Slack talks about in this post. I was sad.

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.

CodeCube 8y ago
lol, I thought the exact same thing
arduinomancer 8y ago
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 8y ago
  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.

deegles 8y ago

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.

malvosenior 8y ago

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 8y ago
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 8y ago
  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.

harel 8y ago

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 8y ago
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 8y ago
  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.
  - xemdetia 8y ago
    I would disagree when it's a clear requirement of the work to be done (and often tossed haphazardly onto a resume). There can be some real time sinks that are not towards making someone productive in a code base as you have to stop and teach them how to think about Git. There's also the fun of having to use advanced Git magic to untangle their PR into something sensible because they've done odd merges along the way where they should have rebased their commits. People that still are from centralized source control only world still exist and getting them to work Git well is a skill that's worth interviewing/filtering over if it's a day 0 expectation.
  - degrews 8y ago
    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.

benmmurphy 8y ago

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.

ed_balls 8y ago

> it would have taken a year to fill our existing open headcount Maybe open an office in a different location or hire remote?

perfect_wave 8y ago

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.

52-6F-62 8y ago
> questioning whether this form of interviewing has some kind of bias. In the case above—the bias is toward experience. I don't think that's a bad thing. Context is important, however. I haven't read any Slack postings, but if they're asking for tangible experience this kind of gatekeeping makes more sense than textbook questions. If they're hiring for an entry-level role then a different approach might be merited.
guitarbill 8y ago
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.

purplezooey 8y ago

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

satokema 8y ago

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.

thaumasiotes 8y ago

> 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 8y ago
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 8y ago
  But that problem doesn't require a process redesign. You can just lower your expectations.

sandGorgon 8y ago

Anyone know what kind of review questions work well ? Any rule of thumbs, best practices to create these questions? Why do they work better ?

iandanforth 8y ago

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.

inertiatic 8y ago

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.

icodemuch 8y ago

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

carimura 8y ago

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