3 ms·

Agree to disagree. You'll never convince me that copy and paste is better then reusing existing code or that it's considered good engineering. And ime, having

by tayo42 3y ago

Agree to disagree. You'll never convince me that copy and paste is better then reusing existing code or that it's considered good engineering. And ime, having a job hacking on Memcached, things like considering locks are extremely important for performance. And a project like Memcached, which is a general purpose network server, meaning it used with a large variety use cases and in different settings and also needs to be consistently fast, you need to carefully think through changes. So again this question is poor imo, it's not clear what you are actually looking for with it. Do you want to see me write code that compiles and does the bare minimum or actually talk about designing a robust feature.

toast0 3y ago
You can (and should!) ask that question if presented with this problem. From the presentation in the article, it seemed like they were looking to see code the compiles and does the bare minimum. From my hiring experience, it can be pretty hard to get bare minimum from candidates, so I've never looked for more beyond that, but I think some of the other people on my teams have looked for more in their interviews. I would rather hire someone who can write code that does what we agreed (or really, what I said) it should, but isn't great at thinking about robustness than someone who can think about robustness but can't write code that does what we agreed it should do. I've worked with lots of people who weren't great about robustness, and have a handle on how to get them up to speed. I've worked with a few people who couldn't code even though it was part of their job, and I don't know how to get them up to speed in a timely manner. I have helped maybe one or two people go from a non-coding job to a coding job, but it's a long process, and I shouldn't need to do it for someone who is supposed to know, so it needs to be tested for in the interview.
ZephyrBlu 3y ago
> You'll never convince me that copy and paste is better then reusing existing code or that it's considered good engineering What's better engineering: not solving the problem, or solving the problem in a sub-optimal way that can be improved upon in future? I don't disagree that performance is important for memcached, but your base assumption here doesn't help you make any progress. You're basically giving up from the start. Assuming that everything you need lives in the incr/decr functionality is a reasonable assumption that lets you make progress. If you assume that performance is important and a multiplication operator may have implications, you should be able to come up with assumptions/hypotheses about why that would be and try to prove or disprove them. > Do you want to see me write code that compiles and does the bare minimum or actually talk about designing a robust feature The great thing about this question is that it forces you to be specific. It's very easy to make general statements like "we need to consider performance implications" without having anything to back that up. Why is the bare minimum insufficient here? Why do you need to deviate from the existing implementation and re-design this operation in a robust way? What makes the existing implementation unsuitable for this use case? Those are the kind of questions I would expect to be answered by someone who is concerned about the performance implications of a multiplication operator. I have found that strong engineers do not pose these vague, open-ended questions and concerns without being able to dig into the underlying details and be able to validate or invalidate their hypotheses.

by tayo42 3y ago

toast0 3y ago

You can (and should!) ask that question if presented with this problem. From the presentation in the article, it seemed like they were looking to see code the compiles and does the bare minimum. From my hiring experience, it can be pretty hard to get bare minimum from candidates, so I've never looked for more beyond that, but I think some of the other people on my teams have looked for more in their interviews. I would rather hire someone who can write code that does what we agreed (or really, what I said) it should, but isn't great at thinking about robustness than someone who can think about robustness but can't write code that does what we agreed it should do. I've worked with lots of people who weren't great about robustness, and have a handle on how to get them up to speed. I've worked with a few people who couldn't code even though it was part of their job, and I don't know how to get them up to speed in a timely manner. I have helped maybe one or two people go from a non-coding job to a coding job, but it's a long process, and I shouldn't need to do it for someone who is supposed to know, so it needs to be tested for in the interview.

ZephyrBlu 3y ago

> You'll never convince me that copy and paste is better then reusing existing code or that it's considered good engineering What's better engineering: not solving the problem, or solving the problem in a sub-optimal way that can be improved upon in future? I don't disagree that performance is important for memcached, but your base assumption here doesn't help you make any progress. You're basically giving up from the start. Assuming that everything you need lives in the incr/decr functionality is a reasonable assumption that lets you make progress. If you assume that performance is important and a multiplication operator may have implications, you should be able to come up with assumptions/hypotheses about why that would be and try to prove or disprove them. > Do you want to see me write code that compiles and does the bare minimum or actually talk about designing a robust feature The great thing about this question is that it forces you to be specific. It's very easy to make general statements like "we need to consider performance implications" without having anything to back that up. Why is the bare minimum insufficient here? Why do you need to deviate from the existing implementation and re-design this operation in a robust way? What makes the existing implementation unsuitable for this use case? Those are the kind of questions I would expect to be answered by someone who is concerned about the performance implications of a multiplication operator. I have found that strong engineers do not pose these vague, open-ended questions and concerns without being able to dig into the underlying details and be able to validate or invalidate their hypotheses.