4 ms·

> topological sort will go out of fashion. If you as a normal software engine write a topological sort algorithm you likely failed your job. Your job is to us

> topological sort will go out of fashion. If you as a normal software engine write a topological sort algorithm you likely failed your job. Your job is to use existing topological sort algorithms designed by people specialized in that area, implemented by people which are specialized in implementing and fine tuning algorithms (it's its whole own field of expertise, and overlooked field tbh.). Or to reformulate it the job of an software engineer is to reuse existing components and basic building blocks to create larger components or programs, but it's not your job to create new basic building blocks. The job requires you to have an understanding of such components but not to memorize them. Sure sometimes you have to create basic building blocks, but then doing so from memory is nearly always the wrong approach. Leet code is not at all representative for "how well someone is suited for given job" (for most companies/offers, there always are exceptions). While wasting everyone's time. And favoring certain skill sets/problem solving approaches (memorization) over others (adaptability, deep generic understanding), at least in the way they tend to be implemented. It also strongly discriminates again anyone with exam anxiety and similar. Be aware that the points mentioned here apply to common leet code based screening (especially automatized screening), but not necessary asking people to solve some code problem in interviews (if you handle that appropriately).

wittycardio 5y ago
If you're a software engineer and you don't know what topological sort is then you don't know how any sort of dependency structure works and that's a big part of your day to day. Implementing topological sort is a few lines of code and anyone should be able to do it
dpryden 5y ago
This hints at an (IMO underrated) skill: being able to look at a problem and decomposing it into sub-problems that are solved by known algorithms. Topological sort is a pretty fundamental building block for solving many problems that involve dependencies between components, since those can be modeled as a directed graph. Knowing how to write a topological sort isn't the key skill here (although, I would argue, it's a good skill to know, and it's probably much simpler than you're imagining). The key skill is knowing that a topological sort will solve the problem, or perhaps it's simply knowing that "finding an order of actions that satisfies these dependency constraints" is called a topological sort. I have always been under the impression that the goal of leetcode-style interviewing was actually to measure a candidate's ability to recognize what algorithmic tool to use, rather than to measure a candidate's ability to implement an algorithm from scratch. When I've been in the position of interviewing in the past, I've always been more interested in that problem-solving approach than in the actual code. In my experience, most software jobs are 90% figuring out the problem that needs to be solved and coming up with tactics for solving the problem, and 10% actually implementing those tactics. In that context, investigating the ability of a candidate to analyze problems seems like an excellent interview technique.
flavius29663 5y ago
It's not about topological sort at all. It might come up in unexpected ways, say cache propagation, or a cyclic dependency in your favorite IoC container. Or in many other possible scenarios that are all real and I see them almost every day
thw09j9m 5y ago
Writing topological sort isn't like rolling your own cryptographic hashing... It's literally 10-20 lines of fairly trivial code. While I get your point, you chose a horrible example.
moonchrome 5y ago
>If you as a normal software engine write a topological sort algorithm you likely failed your job. Your job is to use existing topological sort algorithms designed by people specialized in that area, implemented by people which are specialized in implementing and fine tuning algorithms (it's its whole own field of expertise, and overlooked field tbh.). What standard library ships with it ? I can remember multiple times I've need to implement topological sort in various languages - mostly to detect if there are cycles between dependencies or order actions, it's rather simple, introducing a third party lib for such code is in the leftpad territory and writing a generic interface to generalize graphs would be clunky in a lot of languages.
Hermitian909 5y ago
> If you as a normal software engine write a topological sort algorithm you likely failed your job. No, because the way topological sorts show up in many systems is not amenable to a library. Sometimes you will have unusual caching strategies available to you or the topological sort needs to work with some weird asynchronicity that no library handles well. Even if you do just need a topological sort it's often not worth bringing a library in. It's a simple algorithm implementable in a few lines of code in many languages.

wittycardio 5y ago

If you're a software engineer and you don't know what topological sort is then you don't know how any sort of dependency structure works and that's a big part of your day to day. Implementing topological sort is a few lines of code and anyone should be able to do it

dpryden 5y ago

This hints at an (IMO underrated) skill: being able to look at a problem and decomposing it into sub-problems that are solved by known algorithms. Topological sort is a pretty fundamental building block for solving many problems that involve dependencies between components, since those can be modeled as a directed graph. Knowing how to write a topological sort isn't the key skill here (although, I would argue, it's a good skill to know, and it's probably much simpler than you're imagining). The key skill is knowing that a topological sort will solve the problem, or perhaps it's simply knowing that "finding an order of actions that satisfies these dependency constraints" is called a topological sort. I have always been under the impression that the goal of leetcode-style interviewing was actually to measure a candidate's ability to recognize what algorithmic tool to use, rather than to measure a candidate's ability to implement an algorithm from scratch. When I've been in the position of interviewing in the past, I've always been more interested in that problem-solving approach than in the actual code. In my experience, most software jobs are 90% figuring out the problem that needs to be solved and coming up with tactics for solving the problem, and 10% actually implementing those tactics. In that context, investigating the ability of a candidate to analyze problems seems like an excellent interview technique.

flavius29663 5y ago

It's not about topological sort at all. It might come up in unexpected ways, say cache propagation, or a cyclic dependency in your favorite IoC container. Or in many other possible scenarios that are all real and I see them almost every day

thw09j9m 5y ago

Writing topological sort isn't like rolling your own cryptographic hashing... It's literally 10-20 lines of fairly trivial code. While I get your point, you chose a horrible example.

moonchrome 5y ago

>If you as a normal software engine write a topological sort algorithm you likely failed your job. Your job is to use existing topological sort algorithms designed by people specialized in that area, implemented by people which are specialized in implementing and fine tuning algorithms (it's its whole own field of expertise, and overlooked field tbh.). What standard library ships with it ? I can remember multiple times I've need to implement topological sort in various languages - mostly to detect if there are cycles between dependencies or order actions, it's rather simple, introducing a third party lib for such code is in the leftpad territory and writing a generic interface to generalize graphs would be clunky in a lot of languages.

Hermitian909 5y ago

> If you as a normal software engine write a topological sort algorithm you likely failed your job. No, because the way topological sorts show up in many systems is not amenable to a library. Sometimes you will have unusual caching strategies available to you or the topological sort needs to work with some weird asynchronicity that no library handles well. Even if you do just need a topological sort it's often not worth bringing a library in. It's a simple algorithm implementable in a few lines of code in many languages.