3 ms·

I dont really agree. Package management has a number of pretty well defined patterns (e.g. lockfiles, isolation, semver, transactionality, etc) which solve comm

by pydry 9mo ago

I dont really agree. Package management has a number of pretty well defined patterns (e.g. lockfiles, isolation, semver, transactionality, etc) which solve common use cases that are largely common across package management. It is unfortunately one of the most thankless tasks in software engineering, so these are not applied consistently. This was symbolized quite nicely by google pushing out a steaming turd of a version 1 golang package management putting while simultaneously putting the creator of brew in the no hire pile coz he couldnt reverse a binary tree. In this respect it is a bit like QA - neglected because it is disrespected. What makes it seem like a wicked problem is probably that it is the tip of the software iceberg. It is the front line for every security issue and/or bug, especially the nastiest class of bug - "no man's land" bugs where package A blames B for using it incorrectly and vice versa.

hansvm 9mo ago
Assuming the binary tree thing is the whole story, that still doesn't sound like a terrible choice on Google's part. Your first few years at Google you won't have enough leeway to do something like "make homebrew," and you will have to interact with an arcane codebase. For tree reversal in particular, it shouldn't be any harder than: 1. If you don't know what a binary tree is then ask the interviewer (you probably _ought_ to know that Google asks you questions about those since their interview packet tells you as much, but let's assume you wanted to wing it instead). 2. Spend 5-10min exploring what that means with some small trees. 3. Then start somewhere and ask what needs to change. Clearly the bigger data needs to go left, and the smaller data needs to go right (using an ascending tree as whatever small example you're working on). 4. Examine what's left, and see what's out of order. Oh, interesting, I again need to swap left and right on this node. And this one. And this one. 5. Wait, does that actually work? Do I just swap left/right at every node? <5-10min of frantically trying to prove that to yourself in an interview> 6. Throw together the 1-5 lines of code implementing the algorithm. It's a fizzbuzz problem, not a LeetCode Hard. Even with significant evidence to the contrary, I'd be skeptical of their potential next 1-3 years of SWE performance with just that interview to go off of. That said, do they actually know that was the issue? With 4+ interviews I wouldn't ordinarily reject somebody just because of one algorithms brain-fart. As the interviewer I'd pivot to another question to try to get evidence of positive abilities, and as the hiring manager I'd consider strong evidence of positive abilities from other interviews much more highly than this one lack of evidence. My understanding is that Google (at least from their published performance research) behaves similarly.
cxr 9mo ago
Every package manager lock file format or requirements file is an inferior, ad hoc, formally-specified, error-prone, incompatible reimplementation of half of Git. Supply chain vulnerabilities are a choice. It's a problem you have to opt in to. <https://news.ycombinator.com/item?id=46008744 https://news.ycombinator.com/item?id=46008744>
- spankalee 9mo ago
  There is actually a huge difference between checking in all of your dependencies and checking in a lock-file. Some people work with hundreds of repositories on their local machine and checking in dependencies would lead to massive bloat. It really only works if you primarily work in a single monorepo.
  - deleted 9mo ago
    [deleted]
  - cxr 9mo ago
    > It really only works if you primarily work in a single monorepo. That's simply not true; it doesn't come down to "monorepo-or-not?" It comes down to whether or not the code size of an app's dependencies and transitive dependencies is still reasonable or has gotten out of control. The trend of language package managers to store stuff out of repo (and their recent, reluctant adoption of lockfiles to mitigate the obvious problems this causes*) is and always has been designed to paper over the dependency-size-is-out-of-control problem—that's the reason that this package management strategy exists. You can work on dozens of projects (unrelated; from disjoint domains) that you maintain or contribute to while having all the source for every library/subroutine that's needed to be able to build the app all right there, checked into source control—but it does mean actually having a handle on things instead of just throwing caution to the wind and sucking down a hundred megabytes or more of simultaneously over- and under-engineered third-party dependencies right before build time. It's no different from, "Our app consumes way too much RAM", or, "We don't have a way to build the app aside from installing a monstrously large IDE" (both belonging to the category of, "We could do something about it if we cared to, but we don't.") > There is actually a huge difference between checking in all of your dependencies and checking in a lock-file. Yes, huge difference indeed: the hugeness of YOLO maintainers' dependency trees. * what could possibly go wrong if we devise a scheme to subvert the operations of a tool where the entire purpose of it was to be able to unambiguously keep track of the revisions/content of the source tree at a given point in time?

by pydry 9mo ago

hansvm 9mo ago

Assuming the binary tree thing is the whole story, that still doesn't sound like a terrible choice on Google's part. Your first few years at Google you won't have enough leeway to do something like "make homebrew," and you will have to interact with an arcane codebase. For tree reversal in particular, it shouldn't be any harder than: 1. If you don't know what a binary tree is then ask the interviewer (you probably _ought_ to know that Google asks you questions about those since their interview packet tells you as much, but let's assume you wanted to wing it instead). 2. Spend 5-10min exploring what that means with some small trees. 3. Then start somewhere and ask what needs to change. Clearly the bigger data needs to go left, and the smaller data needs to go right (using an ascending tree as whatever small example you're working on). 4. Examine what's left, and see what's out of order. Oh, interesting, I again need to swap left and right on this node. And this one. And this one. 5. Wait, does that actually work? Do I just swap left/right at every node? <5-10min of frantically trying to prove that to yourself in an interview> 6. Throw together the 1-5 lines of code implementing the algorithm. It's a fizzbuzz problem, not a LeetCode Hard. Even with significant evidence to the contrary, I'd be skeptical of their potential next 1-3 years of SWE performance with just that interview to go off of. That said, do they actually know that was the issue? With 4+ interviews I wouldn't ordinarily reject somebody just because of one algorithms brain-fart. As the interviewer I'd pivot to another question to try to get evidence of positive abilities, and as the hiring manager I'd consider strong evidence of positive abilities from other interviews much more highly than this one lack of evidence. My understanding is that Google (at least from their published performance research) behaves similarly.

cxr 9mo ago

Every package manager lock file format or requirements file is an inferior, ad hoc, formally-specified, error-prone, incompatible reimplementation of half of Git. Supply chain vulnerabilities are a choice. It's a problem you have to opt in to. <https://news.ycombinator.com/item?id=46008744 https://news.ycombinator.com/item?id=46008744>

spankalee 9mo ago
There is actually a huge difference between checking in all of your dependencies and checking in a lock-file. Some people work with hundreds of repositories on their local machine and checking in dependencies would lead to massive bloat. It really only works if you primarily work in a single monorepo.
- deleted 9mo ago
  [deleted]
- cxr 9mo ago
  > It really only works if you primarily work in a single monorepo. That's simply not true; it doesn't come down to "monorepo-or-not?" It comes down to whether or not the code size of an app's dependencies and transitive dependencies is still reasonable or has gotten out of control. The trend of language package managers to store stuff out of repo (and their recent, reluctant adoption of lockfiles to mitigate the obvious problems this causes*) is and always has been designed to paper over the dependency-size-is-out-of-control problem—that's the reason that this package management strategy exists. You can work on dozens of projects (unrelated; from disjoint domains) that you maintain or contribute to while having all the source for every library/subroutine that's needed to be able to build the app all right there, checked into source control—but it does mean actually having a handle on things instead of just throwing caution to the wind and sucking down a hundred megabytes or more of simultaneously over- and under-engineered third-party dependencies right before build time. It's no different from, "Our app consumes way too much RAM", or, "We don't have a way to build the app aside from installing a monstrously large IDE" (both belonging to the category of, "We could do something about it if we cared to, but we don't.") > There is actually a huge difference between checking in all of your dependencies and checking in a lock-file. Yes, huge difference indeed: the hugeness of YOLO maintainers' dependency trees. * what could possibly go wrong if we devise a scheme to subvert the operations of a tool where the entire purpose of it was to be able to unambiguously keep track of the revisions/content of the source tree at a given point in time?