3 ms·

In every real world work problem that is solved collaboratively had some time before where people understood the context and the problem by themselves before. A

by soneca 5y ago

In every real world work problem that is solved collaboratively had some time before where people understood the context and the problem by themselves before. At least they know the codebase, the business goals, the colleague. There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes.

xyzzy_plugh 5y ago
> There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes. I don't know what to say to this beyond, absolutely yes this situation exists. The easiest scenario is you are on call and get paged and must solve a critical issue in as few minutes as possible.
- closeparen 5y ago
  What kind of shop are you working in which requires you to solve algorithms puzzles to resolve outages? Even if we think we see a way to solve an outage with something like this, we generally consider it inappropriate for an outage mitigation scenario, always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Implementing a better or more scalable or more resilient system is important, yes, but is done after the issue is mitigated... not at gunpoint.
  - xyzzy_plugh 5y ago
    > always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Sure, that's nice, but you're living in a fantasy if you expect that to always be possible. I also didn't say anything about implementing scalable or more resilient, or even algorithm puzzles. That's not what we're discussing. I'm talking about communicating when problem solving. If solving an outage was always a mundane rollback or simple intervention, then it should've been automated. For example, say a new deploy corrupted the database subtly. How do you recover it? Perhaps you rollback the deploy, create a new database instance from a backup, perform a cutover, lock writes, write a migration to copy records from the old instance to avoid losing data written since the backup, validate the restore, unlock writes, monitor. You probably also need to work with stakeholders to draft and send comms to customers, document the steps you took, answer questions from product folk. This is what I am trying to get signal on in an interview. How do you work on your feet, when it matters most. If you expect to be able to sit in silence for 30 minutes after you were paged while you draft a solution in your head then you're going to have a bad time. For a junior candidate, these expectations are reduced, but this is the bar for a senior candidates. If I wanted you to solve an algorithm puzzle I'd give you the puzzle and tell you to come back tomorrow. If I didn't think you could solve an algorithm puzzle, we wouldn't be having a conversation. Communication is the whole point.
    - soneca 5y ago
      I think talking through an algorithm puzzle solution during an interview gives you no signal at all of how well an employee would communicate in the scenario you described.

by soneca 5y ago

xyzzy_plugh 5y ago

> There is no situation where a boss call two random engineers, throw a completely new problem at their hands and ask them to solve it in 45 minutes. I don't know what to say to this beyond, absolutely yes this situation exists. The easiest scenario is you are on call and get paged and must solve a critical issue in as few minutes as possible.

closeparen 5y ago
What kind of shop are you working in which requires you to solve algorithms puzzles to resolve outages? Even if we think we see a way to solve an outage with something like this, we generally consider it inappropriate for an outage mitigation scenario, always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Implementing a better or more scalable or more resilient system is important, yes, but is done after the issue is mitigated... not at gunpoint.
- xyzzy_plugh 5y ago
  > always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Sure, that's nice, but you're living in a fantasy if you expect that to always be possible. I also didn't say anything about implementing scalable or more resilient, or even algorithm puzzles. That's not what we're discussing. I'm talking about communicating when problem solving. If solving an outage was always a mundane rollback or simple intervention, then it should've been automated. For example, say a new deploy corrupted the database subtly. How do you recover it? Perhaps you rollback the deploy, create a new database instance from a backup, perform a cutover, lock writes, write a migration to copy records from the old instance to avoid losing data written since the backup, validate the restore, unlock writes, monitor. You probably also need to work with stakeholders to draft and send comms to customers, document the steps you took, answer questions from product folk. This is what I am trying to get signal on in an interview. How do you work on your feet, when it matters most. If you expect to be able to sit in silence for 30 minutes after you were paged while you draft a solution in your head then you're going to have a bad time. For a junior candidate, these expectations are reduced, but this is the bar for a senior candidates. If I wanted you to solve an algorithm puzzle I'd give you the puzzle and tell you to come back tomorrow. If I didn't think you could solve an algorithm puzzle, we wouldn't be having a conversation. Communication is the whole point.
  - soneca 5y ago
    I think talking through an algorithm puzzle solution during an interview gives you no signal at all of how well an employee would communicate in the scenario you described.