No interviewer has demonstrated anything but perfunctory interest in my open source work, popular or not.

It's a myth, like 'nobody cares where you went to school so long as you can do the work'.

That's fascinating, I had the opposite experience.

Never once have I been asked which school I went to or anything about my CS degree. I had multiple people contacting me after finding me on Github (and my OSS work is very unpopular and mostly unmaintained) and one of them was a C-Suite who offered me a job.

I never found a job with a recruiter - just networking, so it may be a form of self selection for more personal interactions.

Seems to me, if a project is successful enough, one could leverage that network to get a job if they needed it. In many companies developers have an outsized influence on which other developers get hired. If I were in this gentlemens shoes that is the angle I would have taken (and maybe he tried). I would have posted a message to the fellow contributors that basically stated:

I had an apartment fire, I am in a jam and am looking for employment as such my contributions to this project may diminish while I focus on my finances, if anyone has any leads at their company please let me know.

Unless one is looking to only work at a FAANG, I suspect something to that effect would net leads for a top developer of a successful project.

I mean, I guess. On the other hand, if you have a niche side project (I have several in a rather niche language), then you become known in the community.

Most people's 'side projects' don't shine on their resume because the side project is just a replica of one hundred other projects that do the same thing. In order to be known for a side project, you have to make sure the audience is small enough for it to make a difference, but large enough that there is commercial interest.

> No interviewer has demonstrated anything but perfunctory interest in my open source work, popular or not.

In he past when I did candidate screening I used floss work extensively to evaluate a candidate. To me, personal projects are an excellent way to assess skillsets at multiple levels.

Perhaps you've been interviewed by people who place a greater focus on soft skills, or HR headhunters who can only read CVs?

I've been a software developer for 15+ years now. It's been the same, every place I've ever interviewed. People place a lower priority on things they can't easily quantify.

I'm proud of the fact that many volunteer collaborators on the D project have, as a direct result, landed very well-paying jobs.

I know it's not the point here, but do those jobs often involve D directly?

Yes, they do. I also get the impression that many employers are looking for people who are more broadly interested in programming beyond C/C++/Java and are willing to pay.

I think it's a part of a bigger problem I see. People are hung up on where they want to work. If you HAVE TO work for certain companies, and you want your finances in order, you're doing it wrong. Priorities!

Also, you don't need most companies or all companies to value your open source project. You need one.

I think that's true for contributions to existing projects or other hard to notice stuff.

On the other hand, I got my current job exclusively via my open source work. But I created a project from scratch.

There's an article that makes the rounds now and again on HN about a engineer who wrote a widely used opensource tool and then didn't get past the Google interview process. FAANGs are still more interested in seeing if you can solve the Knapsack Problem then seeing that you can write good, maintainable code.

It was the developer behind the macOS package manager Homebrew https://twitter.com/mxcl/status/608682016205344768

Sheesh I'd forgotten - he's right, everyone does use that tool. He backed off on a bit but the point still remains, I'm sure he's a better engineer than half of google.

I wonder if they asked Pike and Thompson to invert a binary tree.

https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

I'm not so sure. By his own admission homebrew is not that great a piece of software. There's a lot more that goes into popularity than being good. Being first, marketing and network effects are as or more important than being good.

He

- acknowledges and understands the problems and

- could certainly fix them if paid a Google-sized salary

But he won't dance to the tune of the "Cracking the Coding Interview" juggernaut so to heck with him. Better to spend time memorizing the Floyd Cycle Detection algorithm than produce useful code.

( OK, I may be a bit bitter )

I mean he says he doesn't really know what a b-tree is. That's a pretty basic data structure and kind of table stakes for being a software engineer. Even then, Google gave him a good look with 7 interviews. Just speculating here, but they probably would have given him a chance if he wasn't "often a dick" and "often difficult".

> That's a pretty basic data structure and kind of table stakes for being a software engineer.

It really isn't. You don't need to know what a b-tree is to do most modern software engineering.

> Even then, Google gave him a good look with 7 interviews. Just speculating here, but they probably would have given him a chance if he wasn't "often a dick" and "often difficult".

I think you're right on this one.

> It really isn't. You don't need to know what a b-tree is to do most modern software engineering.

if you're hiring a car driver, then yes, the driver doesn't need to know the innards of how an engine would work.

But if you're hiring a car mechanic, surely you expect them to understand the innards of the engine.

This is not a good analogy. Most cars work in roughly the same way. Most software does not.

Software engineering is a diverse enough topic that you can have two "software engineers" who, aside from very broad general concepts like control flow and modularity, have very little overlap in their areas of expertise. Developing microcontroller firmware requires a very different set of skills and knowledge to building an ML model in R.

Most pieces of software require zero knowledge of the inner workings of, different implementations of, or even existence of a b-tree structure in order to be able to successfully create, understand and maintain them. Let's not gatekeep by telling people they're not real software engineers unless they understand and can recite an arbitrary set of mostly useless topics.

It's actually not a good analogy because most mechanics nowadays specialize. You don't have an engine guy do an automatic transmission rebuild and you don't have your local car dealer do a coil-over 4 link suspension upgrade on your Jeep.

This is exactly analogous to software in that you don't need to know deep algorithms to build CRUD web apps. They are a different part of the machine and closer to the business domain. Looking for deep CS over skills like requirement gathering, collaboration, information theory gives false signals on competency for the task at hand.

The reality is front end, backend, embedded, desktop etc. etc. all have different requirements on the skill sets they need to be successful. People gain the skills they need via the process of working, then we have this ritual of interviewing where we act like all these things that never get used in their trade are so so important to know.

The direct analogy is I am hiring an engine guy,he will never touch a transmission. The guy knows fuel maps, timing and compression ratios like the back of his hand, but I keep insisting that he tell me how the sun gear of the transmission engages the planetaries and in what sequence because he has to know this to be any good as an engine guy and come to the conclusion in my head that if he does not know transmissions it is a signal that he is not fit to be an engine guy.

>The guy knows fuel maps, timing and compression ratios like the back of his hand, but I keep insisting that he tell me how the sun gear of the transmission engages the planetaries and in what sequence because he has to know this to be any good as an engine guy and come to the conclusion in my head that if he does not know transmissions it is a signal that he is not fit to be an engine guy.

Sure, but that's not what happened. The real story, in contrast to the tweet, is that he didn't really know what a b-tree was. And if you're hiring an engine mechanic and they tell you they don't really know what a transmission is, well, that's a pretty big red flag.

Agreed and I don't know what he was applying for, I was just highlighting that this happens a lot in our industry where we misapply (not saying everyone in the tech industry) what we do with the ritual of insisting that applicants are worthy via a cargo cult process of ensuring that they too have the smartest guy in the room mentality.

I hate to entertain this bad analogy further than necessary, but knowing what a gearbox is in the field of cars is not even remotely near the same level as knowing what a b-tree is in the field of software engineering.

I guess we'll just have to disagree. They're a pretty basic data structure that's used quite often to solve a class of problems. And they're not that hard to learn. How they work is pretty simple and the reason to use them is pretty easy to grasp. I would say that there are few good software engineers out there that aren't clear on what they are at a basic level.

I am curious. Which one do you think is more difficult to understand? (I couldnt tell)

You don't need to know what a b- tree is, just a binary tree. The question was about a simple binary tree, which is really trivial, even you have no idea of b-tree's and you never inverted a binary tree yet.

The dick part might be true, esp. after getting 7 interviews.

the only interaction with b-tree's i had was:

CREATE INDEX index ON table (column);

so I doubt the knowledge of b-tree's are that important for 90% of the users/people/developers. heck I know how to write a multipart parser/formatter, which I doubt that many people do. especially people who know how a b-tree works. well most people which do know how a b-tree works, do not know when to use it.

Actually writting good software (from an engineering perspective) is easier than coming up with a popular software. If you dont like the 'easier' statement, I can replace it with 'more important' or 'different'. So maybe he shouldnt work as a programmer for FAANG, but more like a product manager (and let the other people write code for him)

> I wonder if they asked Pike and Thompson to invert a binary tree.

Would surprise me if they couldn't. Writing compilers include lots of working with trees. Pike has literally written a book with a chapter on Algorithms & Data Structures, including trees.

OK I concede that they'd pass it, I suppose I'm just amused at picturing the scene.

"Can you invert a binary tree?"

"I wrote a book on binary trees!"

"That's very nice. The clock is ticking, you now 19 minutes left... "

I picture the scene as:

"...and that's the answer."

"Sorry...you're wrong. That's not how we solve it."

"I wrote the book on it. I just solved it for you starting from first principles. It can be used as a proof."

"Sorry...if you can't think the way we do you just won't fit in."

"I asked you to write an algorithm, not a bunch of Greek letters. Is that your fraternity or something?"

If that's the answer you get, be glad. Dodged a bullet. Go find a job somewhere else where they value your skills. There was no good fit to begin with.

So the plan is to abandon the project? It will work some individuals, but we need something more sustainable for the industry.

If the project is valuable, someone will step in to maintain it.

If nobody does, its value didn't justify the cost of maintenance.

Perhaps all the people using it value it enough that they might pay (if they had no other choice to keep it), but might not be able to maintain it.

In that situation, it's valued but it only gets maintained if someone offers to do the maintenance for pay.

If the current maintainer is stepping down from the project if they aren't paid, but willing to continue for pay, it makes sense for them to let everyone else know they are willing to continue if paid, doesn't it?

If your finances are not in order, you can't be worrying about sustainability of some library or tool, or the industry for that matter. The industry is made out of people. If there are individuals who have to slave away to maintain an important tool or library, it's not going to be sustainable either.