He had an interview with Google and they asked him to invert a binary tree, which is essentially taking a tree of data and swapping the positions of all sibling nodes.
While most people agreed it was a pretty pointless question to ask at an interview, mxcl had a full “don’t you know who I am” shit fit on social media.
It depends on your intent. If you’re doing it to keep history clean and linear in the long term, it’s a huge waste of time as it gets splatted into a single squashed merge commit. It also makes it difficult for reviewers to rereview your changes as GitHub/Lab can’t calculate the diff because you keep moving the goalposts with force pushes.
If you’re doing it for cleanliness on your local branch then I guess that’s fine, but I find it anti-social in a multi participant repo.
Agreed. I’ve been trying to explain to someone recently why rebasing and force pushing their feature branch has no benefit when we use a squash commit strategy for merging to main.
Again, tools are not blame, but when combined with a lack of understanding and accumulated “git dogma”, it can be quite disheartening.
Same. I mostly use sourcetree to do quick self-reviews and to discard lines or hunks before a commit.
But I’ve also grown very weary of having to dig people out of git messes they’ve made with sourcetree and the likes.
Visual clients aren’t to blame for that, but they contribute. So many times I’ve asked “and what git commands did that run?” only to receive a dumb stare as a reply.
Absolutely. I generally find any kind of analogous coding tasks - leetcoder style or otherwise - to be a huge waste of time.
It tells you significantly less than a 30 minute conversation will. Someone who doesn’t know what they’re talking about will out themselves quickly when you get into the nitty gritty of the full software delivery lifecycle.
I have a GCSE in IT, and a degree in CompSci and… I completely agree. You don’t need any of it, relevant experience is worth in the region of 5x-10x for every hiring manager I’ve known, and for myself.
However, it does cause a bootstrapping problem. Getting that first opportunity can be tough, and there’s a good chance that you’ll be filtered out at CV vetting time by a recruiter matching keywords and tallying CV content before you even get to a stage of consideration by hiring managers.
And they both have pros and cons. The pros of not doing a degree are mostly fiscal. I’d advise anyone who can afford the overhead of doing a degree to do one still.
tl;dr - lack of education isn’t and shouldn’t be an obstacle to starting a programming career, but you should still understand what you’re up against in the average hiring process and tune your approach accordingly.
To repeat the other person’s point a bit, what you’re describing sounds very much like LLVM, and other IR languages.
IRs exist to allow a variety of programming languages to be specified in a way that doesn’t require direct compilation of that language to asm. This means the IR has to support some representation of the superset of all those languages’ features.
So I guess your question could be interpreted as: why don’t we just use an IR to write code? Mostly because they require you to forego many of the modern conveniences of modern programming languages. The whole point of going higher level and more opinionated in language choice is to allow you to turn designs into code faster than you can with lower level representations.
I don’t entirely follow what you’re trying to achieve with the plugins idea but it very much sounds like a combination of ideas that are found in LLVM combined with features from modern workbench IDEs. You might want to read about the architecture of Eclipse.
Eclipse was a popular development “workbench” that allowed you to plug in various tools at every level and stage of development and configure them to your taste, as well as allowing you to build your own plugins to work with languages in a bespoke way.
https://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
It’s more about scale. Small open source projects might get one PR a month. Your average tech company is dealing with dozens of PR every single day. Review fatigue is real in these environments