Some bad interview questions are like that, sure. But they're supposed to be things you are very unlikely to have done before and can reasonably figure out. It's not too hard to come up with simple questions like that. (Though I will grant many people don't seem to bother.)
IMO this is not a helpful way to put it. They measure skill under stress. Stress may have a large effect on skill level for some people but highly unlikely that it's so large that performance is completely random.
I failed because I’d misformatted the for loop
Unlikely that you failed the interview because of a basic syntax mistake.
My personal preference when evaluating candidates ability to code is reading their actual production code
This would be a great interview method! But 99% of people are not working on open source code professionally so it doesn't really work in general.
You don't know how good you've got it. The hiring process in other industries is much worse.
Yeah I've seen Nix and Guix suggested but they seem like a huge extra layer of complexity.
Also, strict backwards compatibility in APIs is totally worth it. It makes developing larger systems so much easier.
Usually not for first party code. It adds extra maintenance burden for little benefit.
For example suppose you want to add an extra parameter to a function. In a monorepos you just do that and fix all the compilation errors. Send one PR through CI. Job done.
With submodules... You have to add a new function so it's backwards compatible. Deal with a default value for the old call, maybe add a deprecation warning. Oh and you need to version your library now. Then good luck finding all the places that function is called and updating them...
Yeah me too but if you keep reading they didn't actually "move on" in the way that it sounds.
git submodule update --init --recursive every time you checkout a commit. There's an option to do it automatically but it's super buggy and will break your .git directory.The list goes on... Some of them depend on exactly what you're using them for.
The slightly frustrating thing is that there isn't a great answer for what to use instead. Git subtree has its own problems. Language-specific package managers do too. There aren't any good languages agnostic package managers I know of.
I'm really hoping Jujutsu will come up with a better solution because it is possible. But it's hard, and they are constrained by Git compatibility so I won't hold my breath.
IMO it's not as good a language as Rust, so I wouldn't learn it for the purposes of making something. However it's very easy to learn (at least to a productive level), so you may as well if you want to.
Just work through go by example and see what you think.
By far the best thing about Go is the tooling. Language itself is eh.
Worktrees are great, and a good reason (if you needed any more) to avoid submodules like the plague. Worktrees don't work with submodules.
Yeah you can use it for normal software. It is very complex though, and the documentation assumes you already have a PhD in formal verification.
They used to have Typescript. Looks like they removed it at some point.
Right but that's mostly because the CLI is a mess, not because the fundamental data model is bad.