4 ms·

It's pretty clear to me what's being tested: do you have strong fundamental engineering skills. This kind of problem/situation is a very common pattern. Honest

It's pretty clear to me what's being tested: do you have strong fundamental engineering skills. This kind of problem/situation is a very common pattern. Honestly it sounds like you don't have good engineering intuition. Type 1 engineers as he described them aren't great engineers because they tend to get stuck in analysis paralysis. They don't have good enough intuition to make the right assumptions about the problem that allow them to continue moving forwards. Do you really need to dig into the e.g. locking mechanism? Probably not, because it should be abstracted away or be used/implemented in the incr codepath, which you can copy. Why are you so scared about implementing new multiplication functionality? Do you not trust your ability to figure out a robust solution based on addition? In my experience, Type 1 engineers do not tend to break problems down correctly. You need to break things down so that you can validate/invalidate your assumptions. Having vague concerns that a multiplication implementation might break tends to belie a lack of understanding and trust, since otherwise you would either have specific concerns or be able to use your intuition to make assumptions about the system. "good engineering" is not about going through every detail of a system, it's being able to reason about problems, approaches and solutions coherently and pragmatically.

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.

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.