45 ms·

I definitely appreciate the intent of it, and think measuring along that axis is incredibly important (and rare). But as someone who continually struggles more

I definitely appreciate the intent of it, and think measuring along that axis is incredibly important (and rare). But as someone who continually struggles more to dive into some codebases than my peers, I can say that this task is far too easy and wouldn't help you gauge my ability to do that at all. Something that requires implementing a new feature that isn't a near-mirror of an existing one (ideally one that requires a bit of thought at the design level) would probably be a much better measure, but I don't know what that might be for something like memcached.

deleted 5y ago
[deleted]
ankrgyl 5y ago
That's a great point! We didn't actually think of this question as much of a "measure" (and I think the blog post alludes to this as well with a "Fizz Buzz" analogy). We thought of it more like a filter — if you couldn't pass, then you _may_ not be adept at navigating through a database-y codebase at the pace that was necessary (at that time) for the work we did. We had other questions (which I won't spoil) that tested more complex system-design skills, without having to implement them within an existing codebase. We felt this provided clear independent signals (ability to "hack" within a codebase and ability to reason through complex system design) vs. conflating the two. As the team grew, and we needed folks who were much better at one or the other, this helped us round out the team with folks who excelled at either skill.
sverhagen 5y ago
I think you'd be surprised how many candidates you'd be able to filter out using a very easy task, despite the great credentials touted in their application. That said, I don't think this is a VERY easy task, per se. And even if it were, there's achieving the stated objective, and then there's you taking the ability to demonstrate some additional skills. I'm in the Java world, and whenever I requested candidates doing exercises, them building a solution with no unit tests, or at least not voluntarily acknowledging that omission, would be a red flag. And then I'd ask: let's say this wasn't an exercise, what things would you add before shipping this to production, which would be a great conversation starter around (again) testing (second chance), observability, logging, and so on.

deleted 5y ago

[deleted]

ankrgyl 5y ago

That's a great point! We didn't actually think of this question as much of a "measure" (and I think the blog post alludes to this as well with a "Fizz Buzz" analogy). We thought of it more like a filter — if you couldn't pass, then you _may_ not be adept at navigating through a database-y codebase at the pace that was necessary (at that time) for the work we did. We had other questions (which I won't spoil) that tested more complex system-design skills, without having to implement them within an existing codebase. We felt this provided clear independent signals (ability to "hack" within a codebase and ability to reason through complex system design) vs. conflating the two. As the team grew, and we needed folks who were much better at one or the other, this helped us round out the team with folks who excelled at either skill.

sverhagen 5y ago

I think you'd be surprised how many candidates you'd be able to filter out using a very easy task, despite the great credentials touted in their application. That said, I don't think this is a VERY easy task, per se. And even if it were, there's achieving the stated objective, and then there's you taking the ability to demonstrate some additional skills. I'm in the Java world, and whenever I requested candidates doing exercises, them building a solution with no unit tests, or at least not voluntarily acknowledging that omission, would be a red flag. And then I'd ask: let's say this wasn't an exercise, what things would you add before shipping this to production, which would be a great conversation starter around (again) testing (second chance), observability, logging, and so on.